WM_{ERASEBKGND/PAINT} <-> ScrollWindowEx race
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. 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? -- Dimi.
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?
participants (2)
-
Dimitrie O. Paun -
Rizsanyi Zsolt