https://bugs.winehq.org/show_bug.cgi?id=32304
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED CC| |focht@gmx.net Component|-unknown |user32 Version|unspecified |1.5.18 Resolution|--- |DUPLICATE Summary|Cannot execute |Flexible Renamer v8.4 |FlexibleRenamer |crashes on startup (no | |active window after child | |dialog controls creation)
--- Comment #4 from Anastasius Focht focht@gmx.net --- Hello folks,
the app uses MSScriptControl (provided by 'MSScript.ocx' ActiveX).
An indication is already given in your log:
--- snip --- err:ole:CoGetClassObject no class object {0e59f1d5-1fbe-11d0-8ff2-00a0d10038bc} could be created for context 0x17 err:ole:CoGetClassObject class {0e59f1d5-1fbe-11d0-8ff2-00a0d10038bc} not registered err:ole:CoGetClassObject class {0e59f1d5-1fbe-11d0-8ff2-00a0d10038bc} not registered err:ole:create_server class {0e59f1d5-1fbe-11d0-8ff2-00a0d10038bc} not registered --- snip ---
-> 'winetricks -q msscript'
--- quote --- this application expects GetActiveWindow() returns non-NULL value when it calls. --- quote ---
Reading this made me immediately remember bug 5402 - even after years ;-)
From what I've seen here, the app creates its main user interface using
statically linked MFC (window/controls are named "Afx:", "AfxControlBar..") The problem appears in the second call of 'CreateDialogIndirectParam', when the app code calls 'GetActiveWindow' while still within message handler 'WM_INITDIALOG' case. There is another 'CreateDialogIndirectParam' call before (nested control creation) hence the problem must be already present earlier but doesn't manifest.
For testing purpose I made the top-most parent window which is not a child window the active window in the non-modal case, after the dialog controls are created and the default focus assignment is handled. Basically searching all ancestors until a non-child top window is found which is not a desktop window (the main app window).
It made the apps from both bugs work. The change might not be correct but narrows down an area to investigate further on.
Resolving as dupe of 5402 (I'll refine that one).
Regards
*** This bug has been marked as a duplicate of bug 5402 ***