http://bugs.winehq.org/show_bug.cgi?id=7404
--- Comment #16 from Dmitry Timoshkov dmitry@codeweavers.com 2007-09-06 08:42:43 --- Created an attachment (id=7972) --> (http://bugs.winehq.org/attachment.cgi?id=7972) Make ShowWindow(SW_MINIMIZE) move a top level window to position -32000,-32000
The app creates a new dialog with CreateDialogIndirectParamA, and in its WM_INITDIALOG handler does:
ShowWindow(hwdlg, SW_MINIMIZE); // calls SetWindowPos(SWP_SHOWWINDOW) UpdateWindow(hdlg);
UpdateWindow causes a WM_PAINT, and the app crashes in WM_PAINT handler. The app (or rather mfc42?) simply doesn't expect to receive WM_PAINT for a minimized top level window.
Before my patch ShowWindow(hwdlg, SW_MINIMIZE) didn't set SWP_SHOWWINDOW flag for the SetWindowPos() call, and SetWindowPos() didn't create an update region for a window. The tests show that ShowWindow(hdlg, SW_MINIMIZE) correctly adds the flag SWP_SHOWWINDOW to SetWindowPos(), so that part is correct.
What is not correct, is that under Windows ShowWindow(hwdlg, SW_MINIMIZE) although adds WS_VISIBLE (Wine does as well) actually moves a top level window to position -32000,-32000, i.e. moves it outside of the desktop.
Attached patch implements the same behaviour under Wine, but this uncovers another Wine bug: Wine still generates a WM_PAINT message for such a window. I briefly looked at the code in server/window.c,set_window_pos(), but I'd better leave this to Alexandre. To me it looks like a new visible region of a window should be clipped by parent/desktop, but currently it is not.