Re: [PATCH 9/9] wined3d: Pass WM_SYSCOMMAND(SC_RESTORE) to DefWindowProc.
On 4 December 2014 at 21:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote:
diff --git a/dlls/wined3d/device.c b/dlls/wined3d/device.c index 89ec00a..51dabd4 100644 --- a/dlls/wined3d/device.c +++ b/dlls/wined3d/device.c @@ -4992,6 +4992,16 @@ LRESULT device_process_message(struct wined3d_device *device, HWND window, BOOL
device->device_parent->ops->activate(device->device_parent, wparam); } + else if (message == WM_SYSCOMMAND) + { + if (wparam == SC_RESTORE && !(device->wined3d->flags & WINED3D_NO_SYSCOMMAND_HANDLING)) I'm not really a fan of this kind of double negative. The way the flag is used, it also seems to be about restores in particular instead of syscommands in general.
+ { + if (unicode) + DefWindowProcW(window, message, wparam, lparam); + else + DefWindowProcA(window, message, wparam, lparam); + } + }
if (unicode) return CallWindowProcW(proc, window, message, wparam, lparam); Is this really how it's supposed to work? In particular, should DefWindowProc really always get the message before the application does, or should we give the application a chance first, and only pass to DefWindowProc if it doesn't handle the message?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-12-08 um 12:04 schrieb Henri Verbeet:
+ { + if (unicode) + DefWindowProcW(window, message, wparam, lparam); + else + DefWindowProcA(window, message, wparam, lparam); + } + }
if (unicode) return CallWindowProcW(proc, window, message, wparam, lparam); Is this really how it's supposed to work? In particular, should DefWindowProc really always get the message before the application does, or should we give the application a chance first, and only pass to DefWindowProc if it doesn't handle the message? That's how I read the test results. I get the messages resulting from the WM_SYSCOMMAND(SC_RESTORE) handling before I see the WM_SYSCOMMAND message itself. This is different from the other WM_SYSCOMMAND operations where the WM_SYSCOMMAND arrives first, and the rest of the messages is triggered by the wndproc calling DefWindowProc.
The test doesn't check for the absence of a message at specific points in the message sequence though, so I guess it would not fail if d3d9 called the window proc, then DefWindowProc and then the window proc again. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBAgAGBQJUvP+uAAoJEN0/YqbEcdMw8k8P9iSVe6GAZxoN/C2lcdvlaDNo E1IPKzeAAkD6E9+7t+NscbV10iKKaiH1SWM94ETH6NdJBPQvY3R93/6Nj1BbxFgF GnOgmWmOXb6iUr7XOzV4qeuNlaTk3MYARGT2JQVMa2OvO+Irac/epOTrzNhF0osL jatwgGtmG8SSpdybEZDamkeirE9uci2rBu5tomluh4A3twmaeQ6ZBsfUmL9VmqCE gO+zmuHauPe03UCzz3v/P0iIkgYlIRZcLsJSPFVHEFfG9a5cbo2/sHSFGmCmzlDV TWrkaclu9AmKhXB/1f04E4Jhmei3pdyuOxH+3doZ87KSsOgq07n8n/1ith9JmjCd We3kwQhzQhzzm40C76fx3/lrdjaxy2Ar5k1G1YIu65MFjWOcjyUNcRM3A5gzo61I ZrsxFfKeAUBtmN7ruFSpDdWVqVA9Cj0lxGnOY3L/EWGf/urY5KeFRsHE+hLutvr1 wSUUJQJ0sY9eJdCAWqEQwsFv3QATfwPu8QI6TuifYICp/Lt056bfM1q4rgJjks65 lPVFsdy875aB/1wcaH7afTBLMNEOzqGyIo7CE6o0vK0hOUR7UwQs7Le5q1xAjFr2 ZMhK+uqaZICufoBdQk8q63Dr8mwxj/8LAjnsP3op3ZPiO/YnQf13Q+xst0fxOGSq 3nGMTa9rkf4PD6z8J9A= =nwva -----END PGP SIGNATURE-----
On 19 January 2015 at 13:59, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote:
Am 2014-12-08 um 12:04 schrieb Henri Verbeet:
+ { + if (unicode) + DefWindowProcW(window, message, wparam, lparam); + else + DefWindowProcA(window, message, wparam, lparam); + } + }
if (unicode) return CallWindowProcW(proc, window, message, wparam, lparam); Is this really how it's supposed to work? In particular, should DefWindowProc really always get the message before the application does, or should we give the application a chance first, and only pass to DefWindowProc if it doesn't handle the message? That's how I read the test results. I get the messages resulting from the WM_SYSCOMMAND(SC_RESTORE) handling before I see the WM_SYSCOMMAND message itself. This is different from the other WM_SYSCOMMAND operations where the WM_SYSCOMMAND arrives first, and the rest of the messages is triggered by the wndproc calling DefWindowProc.
It's been a while since I looked at this patch set in detail, but IIRC the test didn't distinguish between DefWindowProc or the application getting the message first. I.e., it would still pass if the application got the message before DefWindowProc instead of the other way around, which arguably would be the more logical order. Perhaps I misremember though.
participants (2)
-
Henri Verbeet -
Stefan Dösinger