http://bugs.winehq.com/show_bug.cgi?id=1265
------- Additional Comments From fsteinel@flonet.net 2003-22-06 12:59 ------- Bug comments restored from Gmane.org:
Tooltip text is drastically cut off, which is a big problem when working in the VFP IDE as Intellisense will tell a developer the syntax for the command being entered.
Download my demo to reproduce.
------- Additional Comments From dclark <at> akamail.com 2003-02-10 13:03 ------- This is being caused because this sequence of events is taking place. Early on the app creates two DCs for the tooltip with a default size of 66x20 pixels. One is an offscreen DC for working in (ends up being 0xa18 on my system), and the other is the DC that is used to actually display the tooltip on the screen (0xa14). When it comes time to show the tooltip, the app moves and resizes both DCs, and paints and writes in the text to the offscreen DC. It then copies this into the screen DC and sends a signal to make it visible. Up to this point everything is fine.
When the window is made visible, some events are received from the X queue, which "catch up" the app. It sends two resize events to the offscreen DC, the first resizes back to 66x20, which effectively clips the rest of the tooltip, and the second resizes it back to the correct size. Unfortunately the contents are now corrupted, but the app is assuming the offscreen DC is ok. The corrupted offscreen DC is then copied to the screen DC.
When the tooltip is hidden and redisplayed, the same sequence of events occurs. Except this time, the DCs were already at the correct size for the tooltip, so no resizing back to 66x20 occurs, and the offscreen DC is not corrupted this time. Even when the window is closed and reopened, it continues to use the DCs it has already created, so no problem occurs.
------- Additional Comments From dclark <at> akamail.com 2003-02-10 15:48 ------- And it looks like this patch fixes this bug. I am not real sure why this code is here, so will have to study more before submitting. And there are already lots of patches setting in the queue already :-)
An X ConfigureNotify event is a notification that a window has just been changed. So it is not clear to me why Wine immediately then changes it again. I will have to test with a bunch of apps to see if I can figure out what (if anything) it is needed for.
Watch out for word wrap.
Index: dlls/x11drv/winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.63 diff -u -r1.63 winpos.c --- dlls/x11drv/winpos.c 8 Jan 2003 21:09:26 -0000 1.63 +++ dlls/x11drv/winpos.c 10 Feb 2003 21:41:08 -0000 @@ -1609,8 +1611,8 @@ /* if nothing changed, don't do anything */ if (winpos.flags == (SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER | SWP_NOACTIVATE)) return;
- SetWindowPos( hwnd, winpos.hwndInsertAfter, winpos.x, winpos.y, - winpos.cx, winpos.cy, winpos.flags | SWP_WINE_NOHOSTMOVE ); +/* SetWindowPos( hwnd, winpos.hwndInsertAfter, winpos.x, winpos.y, + winpos.cx, winpos.cy, winpos.flags | SWP_WINE_NOHOSTMOVE );*/ }
------- Additional Comments From dclark <at> akamail.com 2003-02-10 16:35 ------- It looks like this is a much better fix.
Index: dlls/x11drv/winpos.c =================================================================== RCS file: /home/wine/wine/dlls/x11drv/winpos.c,v retrieving revision 1.63 diff -u -r1.63 winpos.c --- dlls/x11drv/winpos.c 8 Jan 2003 21:09:26 -0000 1.63 +++ dlls/x11drv/winpos.c 10 Feb 2003 22:33:20 -0000 @@ -887,6 +887,9 @@ UINT wvrFlags = 0; BOOL bChangePos;
+ /* This is needed to flush pending X ConfigureNotify events on this window */ + MsgWaitForMultipleObjectsEx( 0, NULL, 0, 0, 0 ); + TRACE( "hwnd %p, swp (%i,%i)-(%i,%i) flags %08x\n", winpos->hwnd, winpos->x, winpos->y, winpos->x + winpos->cx, winpos->y + winpos->cy, winpos->flags);
------- Additional Comments From pmcnett <at> pm-sc.com 2003-02-10 19:35 ------- I didn't try your first fix but the second works!! This is great for Visual FoxPro and Wine...
One thing though, not sure if this should be a separate bug report or not. If I display some ToolTipText, and then switch to a different application, the ToolTipText will be displaying on top of the foreground app's windows as well. Actually, the ToolTipText will be on every desktop workspace, on top of all other windows. I had previously noticed this phenomenon for dockable windows that were currently undocked in the VFP IDE, so I'm assuming this is a separate issue entirely and will likely file a separate bug report in a couple weeks...
------- Additional Comments From chetdude <at> pacbell.net 2003-02-26 15:51 ------- *** This bug has been confirmed by popular vote. ***
------- Additional Comments From wine-devel <at> bol.com.br 2003-04-05 23:59 ------- The second patch solves the bug. Why not to apply to current wine version? And te bug 1266 appear to be resolved, too.
------- Additional Comments From dclark <at> akamail.com 2003-04-06 13:05 ------- Hmm, you assigned the bug to yourself (Marcelo) :-) Adding wine-bugs to the CC list so that further postings show up on gmane.