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.