UpdateWindow vs. WM_PAINT

[Robert Shearman]

Michael Kaufmann wrote:

> Hi,
>
> I've noticed that many Windows controls don't wait for a WM_PAINT 
> message. They redraw themselves immediately (with GetDC/ReleaseDC, 
> UpdateWindow or RedrawWindow). This is necessary if a program is 
> carrying out a lengthy operation without fetching messages. TextPad is 
> such a program: Its progress control doesn't get updated in WINE while 
> loading a file.
>
> To see the redraw differences between Windows and WINE, I've created 
> this test program: 
> http://www.michael-kaufmann.ch/WINE/ControlsRepaintTest.zip
> It changes properties of different controls and then calls Sleep() to 
> simulate a lengthy operation.
>
> The big problem is that it's undocumented in which cases a control 
> should wait for a WM_PAINT message and in which cases it should redraw 
> itself immediately. I've observed that many controls redraw themselves 
> immediately if an important property of the control gets changed (e.g. 
> the position of a progress control, the text of a status bar) or if 
> the user selects an item (ListBox, ListView, TreeView) or if he 
> presses a key (Edit box). Most controls wait for WM_PAINT if the data 
> that they display was modified. But sometimes it's just arbitrary.
>
>
> Examples (tested on Windows 2000):
>
> Edit Control:
>  - Redraw immediately: WM_REPLACESEL, EM_SETSEL, WM_CLEAR, WM_PASTE, 
> WM_CUT
>  - Don't redraw immediately: WM_SETTEXT, EM_UNDO, other messages
>
> Listbox Control:
>  - Redraw immediately: LB_SETCURSEL, LB_SETTOPINDEX
>  - Don't redraw immediately: LB_SETSEL, LB_RESETCONTENT, LB_ADDSTRING, 
> other messages
>
>
> I've created a patch which should work for most lazy programs. Please 
> review it.


I haven't run your test program yet but the changes look good. Submit 
the patch to wine-patches with a change log and hopefully it will be 
committed to cvs.

Rob