On 4 December 2014 at 21:51, Stefan Dösinger stefan@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);elseDefWindowProcA(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);elseDefWindowProcA(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.
On 19 January 2015 at 13:59, Stefan Dösinger stefandoesinger@gmail.com wrote:
Am 2014-12-08 um 12:04 schrieb Henri Verbeet:
{if (unicode)DefWindowProcW(window, message, wparam, lparam);elseDefWindowProcA(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.
-
Henri Verbeet -
Stefan Dösinger