[Bug 2624] In dialogs, an incorrect extra WM_ERASEBKGND is sent after WM_PAINT

http://bugs.winehq.org/show_bug.cgi?id=2624

--- Comment #11 from Mikolaj Zalewski   2007-10-15 18:15:50 ---
The WM_ERASEBKND gets generated because the dlgproc returns FALSE, we call the
DefWindowProc, it calls BeginPaint/EndPaint and it generates a WM_ERASEBKGND
because GetDC doesn't validate the window.

It works under Windows as it seems that there for top-level windows there is an
exception and the WM_ERASEBKGND is not generated by BeginPaint but sent from
outside before WM_PAINT. Thus during WM_PAINT there is no RDW_ERASE and even if
the app doesn't validate the window, no WM_ERASEBKGND occurs (unless the app
e.g. calls RedrawWindow(..., RDW_ERASE|RDW_INVALIDATE) - then there will be an
erase).

In bug #10013 it's more a bit different as GeoInfo calls
BeginPaint{}/EndPaint() in the WM_PAINT handler but it also calls PeekMessage
which receives an X11 expose event and invalidates the window. The dialog proc
returns FALSE thus the default handler is called.

There is also another difference that could affect such apps - a
MoveWindow(..., TRUE) only marks the background for erasing on Wine, while on
Windows is also does an update before the function returns.

I will try to write some tests and fixes at least for the simple case of the
function not calling PeekMessage.