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