http://bugs.winehq.org/show_bug.cgi?id=9969
Summary: OPAS shows error boxes when hovering over calendar item Product: Wine Version: 0.9.46. Platform: Other OS/Version: other Status: NEW Severity: normal Priority: P2 Component: wine-misc AssignedTo: wine-bugs@winehq.org ReportedBy: mikolaj.zalewski@gmail.com
When hovering over a calendar item OPAS hows a popup tooltip with a some more information about the event. On Wine this popup is also shown but then a dialog informs about Visual FoxPro errors (property not found, field not found). This bug is even when using native dcom98, msvcrt, shlwapi and other DLLs that could be easily substituted.
A thing that I have found is that on Windows the tooltip seems not to take the focus from the window while on Wine WM_KILLFOCUS and WM_SETFOCUS messages are sent to transfer the focus to the tooltip. On the next WM_MOUSEMOVE the error occurs.
http://bugs.winehq.org/show_bug.cgi?id=9969
--- Comment #1 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2007-10-10 15:47:42 --- Created an attachment (id=8501) --> (http://bugs.winehq.org/attachment.cgi?id=8501) patch
The problem is that SW_SHOWNOACTIVATE behaves like SW_SHOW on managed Wine windows - the window receives a WM_TAKE_FOCUS (at least on Gnome 2.14.3) and accepts it activating the window. OPAS seems not to be prepared for this. With this patch that makes Wine not accept the WM_TAKE_FOCUS for the tooltip Window the program works fine. Of course the patch is not correct - it only proves where the problem is. OPAS also works fine in a virtual desktop.
http://bugs.winehq.org/show_bug.cgi?id=9969
--- Comment #2 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2007-10-11 16:18:57 --- The problem is that whether this WM_TAKE_FOCUS is sent is WM-dependent - e.g. on FVWM the focus follows the mouse and this problem is not present unless the user moves the mouse so quickly that it hovers over the tooltip (the same is in KDE when one chooses "Focus follows the mouse"). So it looks like ignoring the first WM_TAKE_FOCUS after ShowWindow won't work. There is also nothing special about the window style to make it unmanaged. X Windows is asynchronous so I'd expect removing the WM_TAKE_FOCUS hint for the time of showing the window also won't help.
http://bugs.winehq.org/show_bug.cgi?id=9969
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
--- Comment #3 from Alexandre Julliard julliard@winehq.org 2007-10-12 02:30:53 --- (In reply to comment #2)
There is also nothing special about the window style to make it unmanaged.
If there is nothing special about the style then it should be unmanaged, that's the default. Could you please look into why we decide to make it managed?
http://bugs.winehq.org/show_bug.cgi?id=9969
--- Comment #4 from Mikolaj Zalewski mikolaj.zalewski@gmail.com 2007-10-12 13:32:45 --- The window is created without WS_POPUP nor WS_CHILD so CreateWindowEx adds WS_CAPTION (the parameters to CreateWindowEx are WS_CLIPSIBLINGS|WS_CLIPCHILDREN, WS_EX_TOPMOST|WS_EX_NOPARENTNOTIFY). This makes the window managed in CreateWindow - before WM_CREATE is sent. After CreateWindowEx returns the application uses SetWindowLong to set the style/exStyle to the same values it passed to CreateWindowEx what clear the WS_CAPTION but the window is already managed and stays so.
Later the application seems to process the WM_NCCALCSIZE and add a 16px nonclient area at the top to draw a caption but that probably doesn't affect this problem.
http://bugs.winehq.org/show_bug.cgi?id=9969
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #5 from Dan Kegel dank@kegel.com 2008-04-06 15:05:20 --- Seems to work in wine-0.9.59.
http://bugs.winehq.org/show_bug.cgi?id=9969
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2008-04-18 11:03:29 --- Closing bugs reported fixed in 0.9.60.
-
wine-bugs＠winehq.org