WM_{ERASEBKGND/PAINT} <-> ScrollWindowEx race

[Rizsanyi Zsolt]

Hi!

On Tuesday 01 October 2002 03:52, Dimitrie O. Paun wrote:
> Hi folks,
>
> Some time ago I reported a drawing problem that appeared often
> in the Common Control Spy. The reason it happens there, is that
> that application has a listbox which lists messages, and notification
> received/sent by the control. Well, this listbox scrolls
> automatically (quite fast at that) as there are quite a few
> messages/notifications sent, and if you obstruct it partially
> with a dialog box that you drag around, you can easily replicate
> the bug.

I have seen this problem (or a similar) with MS Word. Checked now, and wine 
notepad does not has the problem.
You can reproduce it by setting a small window (like kcalc :) to 'Allways on 
Top' in front of word, and trying to scroll the document _up_. The Word 
window is not updated below the kcalc window.
Its not a too an big issue, so I'm reporting it only now, when I have seen a 
similar one... This is easier to reproduce :)

Regards
Zsolt

> What happens is that a part of the dialog's caption is scrolled up,
> and not erased. I've attached a snapshot of the problem -- please
> take a look at it.
>
> I was thinking about it, and I think I know what the problem is:
>   1. you drag the dialog box down
>   2. this invalidates a portion of the listbox (this invalidated
>      portion contains part of the old caption of the dialog)
>   3. for whatever reason, the listbox gets new items, and is
>      scrolled (using ScrollWindowEx), *before* it gets a
>      WM_ERASEBKGND/WM_PAINT message.
>   4. ScrollWindowEx scrolls the content of the window *including*
>      the invalidated area which contains the portion of the caption.
>  *5. ScollWindowEx fails to extend the "scroll" update the portion
>      of the update region (wndPtr->hrgnUpdate).
>
> As you can see, the bug happens at step5. That is, if we scroll a
> rectangle that intersects the update region, we have to "scroll"
> the update window as well (in the portion that it intersects).
>
> For example, say we have a simple update region: [0,50,100,100],
> and we scroll the rectangle [0,0,100,60] by 30 units up,
> we have to end up with an update region of [0,20,100,100].
> I don't think that we do, right now.
>
> Can anyone familiar with the code (dlls/x11drv/scroll.c) take
> a look, and see what's going on?