Fixes a regression introduced by 3b5198c8283d891095612c1001edb5e5788d6059. Media Player Classic deadlocks when the window is destroyed, because DestroyWindow will notify the parent, which is on a different thread and waiting on a signal from the filter's thread.
On Windows, when WM_DESTROY is received, it's already detached from the parent. However, manually sending a WM_CLOSE to the window does not detach it (it actually doesn't seem to destroy it, either) which means the detach process is not done in WM_CLOSE in Windows.
Signed-off-by: Gabriel Ivăncescu gabrielopcode@gmail.com ---
Since all of this is implementation detail that I don't think we should go much into, this new version of the patch simply detaches the window before we send the WM_CLOSE ourselves, which does make the app happy and closely resembles Windows behavior.
dlls/strmbase/window.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/dlls/strmbase/window.c b/dlls/strmbase/window.c index 07a12ec..0a2ef9f 100644 --- a/dlls/strmbase/window.c +++ b/dlls/strmbase/window.c @@ -139,6 +139,11 @@ HRESULT WINAPI BaseWindowImpl_DoneWithWindow(BaseWindow *This) if (!This->hWnd) return S_OK;
+ /* Media Player Classic deadlocks when the parent, which is on a different thread, + is notified before the destruction. Windows itself seems to detach the window + from the parent prior to destroying it, so we also do that here as well. */ + IVideoWindow_put_Owner(&impl_from_BaseWindow(This)->IVideoWindow_iface, (OAHWND)NULL); + SendMessageW(This->hWnd, WM_CLOSE, 0, 0); This->hWnd = NULL;