Re: [PROBLEM REPORT] Edit control line scrolling

[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