[Bug 21085] New: Comctl32 status control uses tooltip window wrongly
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(a)winehq.org ReportedBy: us(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 Nikolay Sivov <bunglehead(a)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(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #2 from Jason Edmeades <us(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #3 from Jason Edmeades <us(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #4 from Jason Edmeades <us(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #5 from Nikolay Sivov <bunglehead(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #6 from Austin English <austinenglish(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #7 from Jason Edmeades <us(a)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? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #8 from Nikolay Sivov <bunglehead(a)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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=21085 --- Comment #9 from Austin English <austinenglish(a)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). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=21085 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |ABANDONED --- Comment #10 from Austin English <austinenglish(a)gmail.com> --- Abandoned. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=21085 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #11 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=21085 Nikolay Sivov <bunglehead(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|ABANDONED |--- --- Comment #12 from Nikolay Sivov <bunglehead(a)gmail.com> --- Reopening. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org