-- v2: user32: Call UpdateWindow() after showing a dialog. user32/tests: Test messages when creating a visible modeless dialog.
From: Elizabeth Figura zfigura@codeweavers.com
--- dlls/user32/tests/msg.c | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+)
diff --git a/dlls/user32/tests/msg.c b/dlls/user32/tests/msg.c index 9282896262e..92b52b39d03 100644 --- a/dlls/user32/tests/msg.c +++ b/dlls/user32/tests/msg.c @@ -1922,6 +1922,38 @@ static const struct message WmModalDialogSeq_2[] = { { WM_NCDESTROY, sent }, { 0 } }; +static const struct message create_visible_dialog_seq[] = +{ + { HCBT_CREATEWND, hook }, + { EVENT_OBJECT_CREATE, winevent_hook|wparam|lparam, 0, 0 }, + { WM_SETFONT, sent }, + { WM_INITDIALOG, sent }, + { WM_CHANGEUISTATE, sent|optional }, + { WM_SHOWWINDOW, sent|wparam, 1 }, + { HCBT_ACTIVATE, hook }, + { EVENT_SYSTEM_FOREGROUND, winevent_hook|wparam|lparam, 0, 0 }, + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_NOSIZE|SWP_NOMOVE }, + { WM_ACTIVATEAPP, sent|wparam, 1 }, + { WM_NCACTIVATE, sent|wparam, 0 }, + { WM_ACTIVATE, sent|wparam, 1 }, + { EVENT_OBJECT_FOCUS, winevent_hook|wparam|lparam, OBJID_CLIENT, 0 }, + { WM_SETFOCUS, sent }, + { WM_WINDOWPOSCHANGING, sent|wparam, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, + { EVENT_OBJECT_SHOW, winevent_hook|wparam|lparam, 0, 0 }, + { WM_NCPAINT, sent|wparam, 1 }, + { WM_ERASEBKGND, sent }, + { WM_WINDOWPOSCHANGED, sent|wparam, SWP_SHOWWINDOW|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE|SWP_NOCLIENTSIZE|SWP_NOCLIENTMOVE }, + /* the following 6 messages only appear before windows 8 */ + { WM_NCCALCSIZE, sent|wparam|optional, 0 }, + { WM_NCPAINT, sent|wparam|optional, 1 }, + { WM_ERASEBKGND, sent|optional }, + { WM_MOVE, sent|optional }, + { WM_SIZE, sent|wparam|optional, SIZE_RESTORED }, + { EVENT_OBJECT_LOCATIONCHANGE, winevent_hook|wparam|lparam|optional, 0, 0 }, + { WM_PAINT, sent }, + { WM_CTLCOLORBTN, sent }, + { 0 } +}; /* SetMenu for NonVisible windows with size change*/ static const struct message WmSetMenuNonVisibleSizeChangeSeq[] = { { WM_WINDOWPOSCHANGING, sent|wparam, SWP_FRAMECHANGED|SWP_NOACTIVATE|SWP_NOSIZE|SWP_NOMOVE }, @@ -16195,6 +16227,13 @@ static void test_dialog_messages(void) DestroyWindow(child); DestroyWindow(parent); flush_sequence(); + + hdlg = CreateDialogParamA(0, "TEST_DIALOG", 0, test_dlg_proc, 0); + ok(IsWindow(hdlg), "CreateDialogParam failed\n"); + ok_sequence(create_visible_dialog_seq, "create visible dialog", TRUE); + EndDialog(hdlg, 0); + DestroyWindow(hdlg); + flush_sequence(); }
static void test_enddialog_seq(HWND dialog, HWND owner)
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; }
On Wed Mar 12 21:47:44 2025 +0000, Elizabeth Figura wrote:
changed this line in [version 2 of the diff](/wine/wine/-/merge_requests/7403/diffs?diff_id=163457&start_sha=bc3e5900e6f2fb0ddae059ec856ce196dcd1c662#dbb014ba84f69658ce8ec4c14bdd7b1b076ce0c0_706_706)
I've taken the liberty of adjusting the previous line to match the usual Wine style.
This has been languishing without comment for 4 weeks. Can I have a hint as to what might be wrong, please?
FWIW, I see two potential problems:
* the approach to formatting is not really an improvement since this adds another badly formatted line—I would appreciate what the preferred solution would be here, since the existing advice is vague if not contradictory;
* there is a concern that this is not the right place or the right way to trigger WM_PAINT. The tests do seem to clearly show that WM_PAINT is sent synchronously for dialogs, and that it is *not* sent synchronously for regular windows, nor is it sent when showing or focusing a window as the dialog initialization code does. I don't see anywhere else WM_PAINT can be sent, and if there's another function we could be calling instead of UpdateWindow(), I am not aware of a way to test that that it is more correct.
The first version had test failures, sorry that I missed the update.