http://bugs.winehq.org/show_bug.cgi?id=21085
Summary: Comctl32 status control uses tooltip window wrongly Product: Wine Version: 1.1.35 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: comctl32 AssignedTo: wine-bugs@winehq.org ReportedBy: us@edmeades.me.uk
I've been debugging a private application and tracked down the source of a trap to the way the status control initializes and uses the tooltip control.
The application in question traps because it receives a WM_CREATE message for the tooltip window and calls GetWindowLong against an hwnd for a value it should have set earlier - this fails but the code doesnt notice, and results in a trap.
On windows, the status control does not create the tooltip until the first WM_MOUSEMOVE event, and hence all application initialization would have finished in my case. You can clearly see this by use of a simple application with a statusbar control set to have a tooltip and text, and then use SPY++ to monitor the window creation messages.
Note this also shows a 2nd problem which is that the status control passes the tooltip text to the tooltip window to manage. This is wrong, because using the status bar you can set and then get the tooltip text before the tooltip window is ever created. Additionally, SPY++ shows that the notify messages (NEEDTEXT type) are sent to the status window when the tooltip needs the text, both of which mean that the status control should manage the text.
I have a simple application which has a button for get tip, set tip text, and using it you can see the behaviour above. It doesnt replicate the trap but you can see the behavious using it - you dont get a WM_CREATE for the tooltip until such time as you move the mouse into the statusbar area on windows.
Simple workarounds for me: winetricks comctl32, or modifying the STATUSBAR_WMCreate method to something like "if (0 && dwStyle & SBT_TOOLTIPS) {" to prevent the tooltip altogether.
JECC
JECC