[Bug 1265] ToolTip text is cut off (Visual FoxPro)

[Wine Bugs]

http://bugs.winehq.com/show_bug.cgi?id=1265





------- Additional Comments From fsteinel at 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.

-- 
Configure bugmail: http://bugs.winehq.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.