https://bugs.winehq.org/show_bug.cgi?id=35650
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |richedit Summary|CA ERWIN Data Modeler r8.2 |CA ERWIN Data Modeler r8.2 |installer EULA can't be |installer EULA can't be |accepted |accepted (RichEdit: missing | |notification messages to | |parent for scroll event)
--- Comment #1 from Anastasius Focht focht@gmx.net --- Hello folks,
it seems some msi custom action which in turn calls an InstallShield engine custom action handles the EULA dialog.
ORCA dump:
--- snip --- LaunchEULA 1 DLLWRAP.DLL DLL1 --- snip ---
'DLL_{A949562F-38AC-4D79-B03F-61D31F767BC5}.ini':
--- snip --- Return=[CA_EULA_Agree],NUMBER Module=ERwinISCustomActions.dll Func=ERISDisplayEULA Arg0=in,MsiHandle,NUMBER Silent=No Source=Binary,NewBinary25 [ProductCode] ProductCode={A949562F-38AC-4D79-B03F-61D31F767BC5} --- snip ---
Trace log:
--- snip --- $ WINEDEBUG=+tid,+seh,+relay,+msi wine ./ERwinDM-r823-3355b.exe ... 0025:trace:msi:MSI_EvaluateConditionW 1 <- L"1" 0025:trace:msi:msi_dialog_send_event Sending control event L"DoAction" L"LaunchEULA" ... 0025:trace:msi:dialog_event_handler handling event L"DoAction" 0025:trace:msi:ACTION_PerformAction Performing action (L"LaunchEULA") ... 0025:trace:msi:ACTION_CustomAction Handling custom action L"LaunchEULA" (1 L"DLLWRAP.DLL" L"DLL1") 0025:trace:msi:HANDLE_CustomType1 Calling function L"DLL1" from L"C:\users\focht\Temp\msi5dcf.tmp" ... 002d:Starting thread proc 0x7ece4a32 (arg=0x8bfac4) 002d:trace:msi:DllThread custom action (2d) started ... 002d:trace:msi:ACTION_CallDllFunction calling L"DLL1" ... 002d:Call KERNEL32.LoadLibraryA(00e559e9 "C:\users\focht\Temp\ERwinISCustomActions.dll") ret=0046ace5 ... 002d:Call PE DLL (proc=0xd668f2,module=0xd60000 L"ERwinISCustomActions.dll",reason=PROCESS_ATTACH,res=(nil)) ... 002d:Call KERNEL32.GetProcAddress(00d60000,00e55879 "ERISDisplayEULA") ret=0046ada8 002d:Ret KERNEL32.GetProcAddress() retval=00d622a0 ret=0046ada8 ... 002d:Call KERNEL32.CreateFileW(008bfff8 L"C:\users\focht\Temp\{A949562F-38AC-4D79-B03F-61D31F767BC5}\EULA_en.rtf",80000000,00000000,0137a4bc,00000003,00000080,00000000) ret=78a34f66 002d:Ret KERNEL32.CreateFileW() retval=000000d8 ret=78a34f66 002d:Call KERNEL32.GetFileSize(000000d8,0137a6ec) ret=78a35261 002d:Ret KERNEL32.GetFileSize() retval=0001eba6 ret=78a35261 ... --- snip ---
The InstallShield engine custom action creates a modal dialog with embedded RichEdit control and two buttons (using MFC).
The 'agree' button is disabled on startup and ought to be enabled when the user scrolled to the end of EULA text.
There is not much to see in trace log itself, most of the logic is buried in MFC code. After some debugging I found the problem to be in Wine's RichEdit control ;-) The difference is just a number of MFC calls missing in between.
Workaround: 'winetricks riched20'
--- snip --- ... 002c:trace:win:WIN_CreateWindowEx L"I &agree" L"Button" ex=00000004 style=58010000 494,328 87x33 parent=0x10086 menu=0x2712 inst=0xf70000 params=(nil) 002c:trace:win:dump_window_styles style: WS_CHILD WS_VISIBLE WS_DISABLED WS_TABSTOP 002c:trace:win:dump_window_styles exstyle: WS_EX_NOPARENTNOTIFY 002c:trace:win:WIN_SetWindowLong 0x10092 -12 2712 W 002c:trace:win:GetWindowRect hwnd 0x10092 (1155,683)-(1242,716) 002c:trace:win:invalidate_dce 0x10092 parent 0x10086 (1155,683)-(1242,716) ((661,355)-(661,355)) 002c:trace:win:invalidate_dce 0x8b9620: hwnd 0x10020 dcx 00000013 Cache 002c:trace:win:invalidate_dce 0x146450: hwnd 0x1008a dcx 00000022 Cache 002c:trace:win:GetWindowRect hwnd 0x1008a (837,360)-(1242,669) 002c:trace:win:set_window_pos win 0x10092 surface (nil) -> (nil) 002c:trace:win:WIN_CreateWindowEx hwnd 0x10092 cs 494,328 87x33 ... 002c:CALL mfc90u.2074(00000115,00000008,00000000) ret=78a3e369 002c:trace:msg:WINPROC_CallProcWtoA (hwnd=0x1008a,msg=WM_VSCROLL,wp=00000008,lp=00000000) 002c:CALL mfc90u.321(00f7c3a0) ret=00f75fee 002c:RET mfc90u.321() retval=0a35642c ret=00f75fee 002c:CALL mfc90u.1274(00010086,0000004e,0000271a,0a357138) ret=00f76003 002c:CALL mfc90u.6800(0000004e,0000271a,0a357138) ret=78a3e29a 002c:CALL mfc90u.5512(0000004e,0000271a,0a357138,0a356374) ret=78a3f674 002c:CALL mfc90u.5154(0000271a,0a357138,0a3562d0) ret=78a3f739 002c:CALL mfc90u.4664(0000004e,0000271a,0a357138,0a3562d0) ret=78a4095d 002c:CALL mfc90u.3286() ret=78a6d338 002c:RET mfc90u.3286() retval=789e9278 ret=78a6d338 002c:RET mfc90u.4664() retval=00000000 ret=78a4095d 002c:CALL mfc90u.4682(0000271a,004e0700,0a35629c,00000000) ret=78a3ff85 002c:CALL mfc90u.3685(00000001,0a356208,00000017) ret=00f7145c 002c:CALL mfc90u.3682(00000001) ret=78a404a4 002c:RET mfc90u.3682() retval=00000000 ret=78a404a4 002c:RET mfc90u.3685() retval=00000001 ret=00f7145c 002c:CALL mfc90u.3687(00000001) ret=00f71475 002c:CALL mfc90u.3682(00000001) ret=78a4035b 002c:RET mfc90u.3682() retval=00000000 ret=78a4035b 002c:RET mfc90u.3687() retval=00005550 ret=00f71475 002c:CALL mfc90u.2360(00000001) ret=00f71490 002c:trace:win:EnableWindow ( 0x10092, 1 ) --- snip ---
At the point of receiving SB_ENDSCROLL (user released scrollbar), the button control parent window proc ought to be called through WM_NOTIFY which in turn retrieves scroll info to determine if the scroll bar reached the bottom.
Native sends WM_NOTIFY which allows the parent proc (dialog window) to do further processing (not only limited to WM_VSCROLL case). Without notify messages the code that checks the scroll info (MFC) is never called.
For testing I sent WM_NOTIFY in ME_HandleMessage/WM_VSCROLL case (using ME_FilterEvent helper) and it worked: the button got enabled as soon as the scroll bar reached the bottom, allowing the EULA to be accepted.
Regards