[PATCH v2 2/2] quartz/tests: Test video window parent's WM_DESTROY notification.

Gabriel Ivăncescu gabrielopcode at gmail.com
Fri Jan 10 10:33:20 CST 2020

On 10/01/2020 17:37, Dmitry Timoshkov wrote:
> Gabriel Ivăncescu <gabrielopcode at gmail.com> wrote:
>> +        /* The WM_DESTROY notification is not sent to the owner, even if the style is off */
>> +        hr = IFilterGraph2_QueryInterface(graph, &IID_IVideoWindow, (void**)&videownd);
>> +        ok(hr == S_OK, "Got hr %#x.\n", hr);
>> +        hr = IVideoWindow_put_Owner(videownd, (OAHWND)parent);
>> +        ok(hr == S_OK, "Got hr %#x.\n", hr);
>> +        IVideoWindow_Release(videownd);
>> +        ok(!(GetWindowLongW(hwnd, GWL_EXSTYLE) & WS_EX_NOPARENTNOTIFY), "Window has WS_EX_NOPARENTNOTIFY.\n");
>>       }
>>       else
>>           skip("Could not find renderer window.\n");
>> @@ -4285,6 +4324,9 @@ static void test_window_threading(void)
>>       ok(!ref, "Got outstanding refcount %d.\n", ref);
>>       ret = DeleteFileW(filename);
>>       ok(ret, "Failed to delete file, error %u.\n", GetLastError());
>> +
>> +    DestroyWindow(parent);
>> +    UnregisterClassA("TestParent", cls.hInstance);
>>   }
> It would be also helpful to test if the window gets subclassed, setting
> WS_EX_NOPARENTNOTIFY on WM_CLOSE doesn't look like a plausible explanation,
> it's rather a hack that seems to work. Probably it's better to put some
> effort to figuring out what is going on and how this works on Windows.

Yeah I'll do a bit more investigations on this with subclassing the 
video window and checking it under Windows, but that's not going to end 
up in wine tests since it's too much of a hack / implementation detail. 
However, it will help with understanding the picture a bit better.

FWIW I'll probably go with unparenting the window on WM_CLOSE instead. 
Does that seem more reasonable / less of a hack?

It's not strictly about WM_CLOSE itself, it just has to happen before 
DestroyWindow gets called.


More information about the wine-devel mailing list