Procite and Wine

[Duane Clark]

On c.e.m.w Uwe Bonnes wrote:
> Duane Clark <junkmail at junkmail.com> wrote:
> : This is a multi-part message in MIME format.
> : --------------040608050206010706050208
> : Content-Type: text/plain; charset=us-ascii; format=flowed
> : Content-Transfer-Encoding: 7bit
> 
> : Duane Clark wrote:
> :> ...
> :> Try this simple patch and see if it fixes it:
> :> ...
> 
> : Hmmm, that came out kind of poorly. Here it is as an attachment.
> 
> This makes the the java application ChipView from the Xilinx webpack much
> more usable (beside all those deficencies you expect form a java
> application: delay and exceptions..) 
> 
> Please discuss (again?) on wine-devel.
> 
> Bye

Okay (switching from c.e.m.w to wine-devel), this had not yet been 
discussed on wine-devel, nor had I submitted the patch. It was one of 
those things I did awhile ago, and was going to look into more, but 
never got around to.

I found this problem on two applications, and now it is apparently 
showing up on two more.

On c.e.m.w Dong Wook Ko wrote:
 > Does anyone know where I should look for in order to use procite 
under wine?
 >
 > I got procite installed, and it sort of runs, but I can see it's
 > flickering very quickly, and my console is flooded with the same error
 > message:
 >
 > err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 30a4!
 >
 > And I cannnot open individual index of the bibs.
 >
 > Any help would be grateful.
 >
 > ps. If anyone could tell me how to export procite into bibtex, I won't
 > have to bother with this...
 >


I have seen this in two other programs. The problem appears to be here,
at about line 779 in windows/painting.c:
	else /* entire window or client depending on RDW_FRAME */
          {
	    if( flags & RDW_FRAME )
		hRgn = 1;
	    else
	    {
		GETCLIENTRECTW( wndPtr, r2 );
                  hRgn = CreateRectRgnIndirect( &r2 );
              }
          }

Reading the MS docs, it appears to me that in this case RDW_FRAME should
be ignored. What happens is the program has an area that needs to be
repainted, but this part of the code causes only a portion to be 
repainted, leaving a portion of the screen still "invalidated". This 
causes another paint request, which since nothing has changed, still 
does not result in the correct repainting. And so it is stuck in an 
indefinite loop.

This rather simple patch appears to fix things, but I did not submit it 
because it did not completely clear up the screen corruption (for 
example testing on Kaleidegraph, for which a free download is available 
somewhere...), though it did stop this bug:




-------------- next part --------------
Index: windows/painting.c
===================================================================
RCS file: /home/wine/wine/windows/painting.c,v
retrieving revision 1.71
diff -u -r1.71 painting.c
--- windows/painting.c	5 Jul 2002 01:23:31 -0000	1.71
+++ windows/painting.c	25 Jul 2002 00:44:15 -0000
@@ -779,15 +779,9 @@
 		OffsetRect( &r2, pt.x, pt.y );
 	    hRgn = CreateRectRgnIndirect( &r2 );
 	}
-	else /* entire window or client depending on RDW_FRAME */
+	else /* entire window */
         {
-	    if( flags & RDW_FRAME )
 		hRgn = 1;
-	    else
-	    {
-		GETCLIENTRECTW( wndPtr, r2 );
-                hRgn = CreateRectRgnIndirect( &r2 );
-            }
         }
     }