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
http://bugs.winehq.org/show_bug.cgi?id=21085
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Comctl32 status control |Status control creates |uses tooltip window wrongly |tooltip window too early
--- Comment #1 from Nikolay Sivov bunglehead@gmail.com 2009-12-19 17:44:00 --- Hi, Jason.
It's nice you are able to debug this. Please open another report regarding tooltip text usage.
Could you add a test case to Wine testsuite?
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #2 from Jason Edmeades us@edmeades.me.uk 2009-12-19 17:55:31 --- Created an attachment (id=25287) --> (http://bugs.winehq.org/attachment.cgi?id=25287) Source for testcase
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #3 from Jason Edmeades us@edmeades.me.uk 2009-12-19 17:55:55 --- Created an attachment (id=25288) --> (http://bugs.winehq.org/attachment.cgi?id=25288) Compiled exe on windows
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #4 from Jason Edmeades us@edmeades.me.uk 2009-12-19 17:58:42 --- I dont think it makes sense to have a 2nd bug, as deferring the initialization but not fixing the tooltip use will break applications which set the tooltip before the mouse enters the control!
Attached is a simple ugly app to demonstrate the issues Click 'open' icon (sorry!) to set a tooltip Click 'close' icon (sorry again) to query the tooltip and display it Use SPY++ on the application once loaded and you'll see the WM_CREATE following the WM_MOUSEMOVE into the statusbar (and if you do a process view you'll see the tooltip window is created at that time)
Unfortunately I dont have time currently to write a test or fix this (its not too difficult to fix, not sure on the testcase) as I'm debugging this for a friend on a very slow VM image - apologies.
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2009-12-22 15:00:34 --- (In reply to comment #4)
I dont think it makes sense to have a 2nd bug, as deferring the initialization but not fixing the tooltip use will break applications which set the tooltip before the mouse enters the control!
Fair enough.
Attached is a simple ugly app to demonstrate the issues Click 'open' icon (sorry!) to set a tooltip Click 'close' icon (sorry again) to query the tooltip and display it Use SPY++ on the application once loaded and you'll see the WM_CREATE following the WM_MOUSEMOVE into the statusbar (and if you do a process view you'll see the tooltip window is created at that time)
Looks like that. Another issues here: - tooltip window does have Desktop as parent and tools have status bar as parent, at least TTN_GETDISPINFO tells that; - status bar forwards messages TTN_GETDISPINFO to its parent (I don't know always or not).
Please open new bugs for that when you have time.
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #6 from Austin English austinenglish@gmail.com 2011-10-02 11:45:40 CDT --- This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.3.29 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #7 from Jason Edmeades us@edmeades.me.uk 2011-10-02 13:59:24 CDT --- I dont have a Linux box to confirm, but the application in question (an in house one where I work) apparently still traps in the same way on modern wine so I really doubt its fixed. Have you tried the testcase attached to the bug?
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #8 from Nikolay Sivov bunglehead@gmail.com 2011-10-03 09:19:23 CDT --- (In reply to comment #6)
This is your friendly reminder that there has been no bug activity for 1 year. Is this still an issue in current (1.3.29 or newer) wine?
It's not fixed, I don't remember any changes in this control for a while.
http://bugs.winehq.org/show_bug.cgi?id=21085
--- Comment #9 from Austin English austinenglish@gmail.com 2013-11-13 16:49:38 CST --- This is your friendly reminder that there has been no bug activity for 2 years. Is this still an issue in current (1.7.6 or newer) wine? If so, please attach the terminal output in 1.7.6 (see http://wiki.winehq.org/FAQ#get_log).
https://bugs.winehq.org/show_bug.cgi?id=21085
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED
--- Comment #10 from Austin English austinenglish@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=21085
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=21085
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|ABANDONED |---
--- Comment #12 from Nikolay Sivov bunglehead@gmail.com --- Reopening.
-
wine-bugs＠winehq.org