From: Sebastian Lackner sebastian@fds-team.de
This partially reverts 52146f62fd28bc1a791734b9939378267140b095.
As stated in that commit, a WM_PAINT will eventually be generated via window exposure. However, some applications rely on WM_PAINT being sent synchronously. As create_visible_dialog_seq shows, this happens reliably, and the behaviour is specific to dialogs.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=35652 --- dlls/user32/dialog.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dlls/user32/dialog.c b/dlls/user32/dialog.c index 661a5cda752..b337adfe32f 100644 --- a/dlls/user32/dialog.c +++ b/dlls/user32/dialog.c @@ -703,7 +703,8 @@ static HWND DIALOG_CreateIndirect( HINSTANCE hInst, LPCVOID dlgTemplate,
if (template.style & WS_VISIBLE && !(GetWindowLongW( hwnd, GWL_STYLE ) & WS_VISIBLE)) { - NtUserShowWindow( hwnd, SW_SHOWNORMAL ); /* SW_SHOW doesn't always work */ + NtUserShowWindow( hwnd, SW_SHOWNORMAL ); /* SW_SHOW doesn't always work */ + UpdateWindow( hwnd ); } return hwnd; }