[PROBLEM REPORT] Edit control line scrolling

[Gerard Patel]

With programs using a multiline edit control, such as Notepad (I'm using Win3.11
version) or Eudora Light 1.5 with mails from the 'In' mailbox (this is a 32 bits
application), scrolling down the edit buffer line by line mostly does not work.

In fact, it works only if the edit buffer size is an exact multiple of the
line height.

In all other cases, the format rectangle is smaller than the client size,
and when
the edit control tries to redraw the last line, the update rectangle is
wrong : only the
lower part of the line is drawn.

I think that this problem can be traced to the replacement of code in
ScrollWindowEx
by the call to ScrollDC.

What is happening is that the client rectangle is scrolled, but the client
rectangle is
bigger than the formatting rectangle by a few pixels; these pixels are
missing in 
the update region.

In Wine previous version, the client rectangle was first ANDed with the
so-called
'visible region' (hvisRgn), so the result was not bigger than the format
rectangle
before being scrolled, then diff-ed with it.

The following patch works around this problem.

I don't have time to investigate further as I am taking one week of
holidays :-) but if someone is interested in the edit control....

Gerard

Index: dlls/x11drv/scroll.c
===================================================================
RCS file: /home/wine/wine/dlls/x11drv/scroll.c,v
retrieving revision 1.2
diff -u -r1.2 scroll.c
--- dlls/x11drv/scroll.c        2001/06/20 00:18:48     1.2
+++ dlls/x11drv/scroll.c        2001/07/22 22:12:06
@@ -114,7 +114,7 @@
         hrgn2 = CreateRectRgnIndirect( &rect );
         if (hrgn) SetRectRgn( hrgn, rClip.left, rClip.top, rClip.right,
rClip.bottom );
         else hrgn = CreateRectRgn( rClip.left, rClip.top, rClip.right,
rClip.bottom );
-        CombineRgn( hrgn, hrgn, hrgn2, RGN_AND );
+        CombineRgn( hrgn2, hrgn, hrgn2, RGN_AND );
         OffsetRgn( hrgn2, dx, dy );
         CombineRgn( hrgn, hrgn, hrgn2, RGN_DIFF );

[Bill Medland]

Gerard Patel  wrote in article
...
> With programs using a multiline edit control, such as Notepad (I'm using

Win3.11
> version) or Eudora Light 1.5 with mails from the 'In' mailbox (this is a

32 bits
> application), scrolling down the edit buffer line by line mostly does not

work.
> In fact, it works only if the edit buffer size is an exact multiple of

the
> line height.
>
> In all other cases, the format rectangle is smaller than the client size,
> and when
> the edit control tries to redraw the last line, the update rectangle is
> wrong : only the
> lower part of the line is drawn.
>
> I think that this problem can be traced to the replacement of code in
> ScrollWindowEx
> by the call to ScrollDC.
>
> What is happening is that the client rectangle is scrolled, but the

client
> rectangle is
> bigger than the formatting rectangle by a few pixels; these pixels are
> missing in 
> the update region.
>
> In Wine previous version, the client rectangle was first ANDed with the
> so-called
> 'visible region' (hvisRgn), so the result was not bigger than the format
> rectangle
> before being scrolled, then diff-ed with it.
>
> The following patch works around this problem.
>
> I don't have time to investigate further as I am taking one week of
> holidays :-) but if someone is interested in the edit control....
>
> Gerard
> Index: dlls/x11drv/scroll.c
>
> RCS file: /home/wine/wine/dlls/x11drv/scroll.c,v
> retrieving revision 1.2
> diff -u -r1.2 scroll.c
> --- dlls/x11drv/scroll.c        2001/06/20 00:18:48     1.2
> +++ dlls/x11drv/scroll.c        2001/07/22 22:12:06
> @@ -114,7 +114,7 @@
>          hrgn2 = CreateRectRgnIndirect( &rect );
>          if (hrgn) SetRectRgn( hrgn, rClip.left, rClip.top, rClip.right,
> rClip.bottom );
>          else hrgn = CreateRectRgn( rClip.left, rClip.top, rClip.right,
> rClip.bottom );
> -
>    CombineRgn( hrgn, hrgn, hrgn2, RGN_AND );
> -
>    CombineRgn( hrgn2, hrgn, hrgn2, RGN_AND );
>    OffsetRgn( hrgn2, dx, dy );
>    CombineRgn( hrgn, hrgn, hrgn2, RGN_DIFF );

If anyone does start looking at this, watch out for the following.  I
haven't looked closely and admit that I probably left the code very
slightly incorrect for a degenerate case.

I think that in the case of a single border (is WS_BORDER, no WS_CLIENTEDGE
etc) then the edit control fiddles things so that it pretends it doesn't
have a border (i.e. there is no non-client rectangle) and it draws the
border itself.  This is possibly unusual; I believe that most controls
leave the border drawing to the NC_ code.

Since I don't think WS_BORDER is specified alone in most cases I doubt if
this is a problem in reality.

Bill