Use MsgWaitForMultipleObjects as suggested by API documentation

WaitForMultipleObjects documentation [1] tells:

  If a thread creates any windows, it must process messages.
  Message broadcasts are sent to all windows in the system. A
  thread that uses a wait function with no time-out interval may
  cause the system to become deadlocked. Two examples of code
  that indirectly creates windows are DDE and the CoInitialize
  function. Therefore, if you have a thread that creates windows, use
  MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx,
  rather than WaitForMultipleObjects

The code calls CoInitialize, so follow the documentation advise.

[1] https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitformultipleobjects

Change-Id: I458234a3c99936e30e5b84224644542e980726dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94678
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>

1 files changed, 7 insertions, 1 deletions

diff --git a/dtrans/source/win32/clipb/MtaOleClipb.cxx b/dtrans/source/win32/clipb/MtaOleClipb.cxx
index 2fdc2d7f9641..70fce3bc64ad 100644
--- a/dtrans/source/win32/clipb/MtaOleClipb.cxx
+++ b/dtrans/source/win32/clipb/MtaOleClipb.cxx
@@ -684,8 +684,14 @@ unsigned int WINAPI CMtaOleClipboard::clipboardChangedNotifierThreadProc( LPVOID
     // a boolean variable like m_bRun...
     while ( pInst->m_bRunClipboardNotifierThread )
     {
+        // process window messages because of CoInitialize
+        MSG Msg;
+        while (PeekMessageW(&Msg, nullptr, 0, 0, PM_REMOVE))
+            DispatchMessageW(&Msg);
+
         // wait for clipboard changed or terminate event
-        WaitForMultipleObjects( 2, pInst->m_hClipboardChangedNotifierEvents, false, INFINITE );
+        MsgWaitForMultipleObjects(2, pInst->m_hClipboardChangedNotifierEvents, false, INFINITE,
+                                  QS_ALLINPUT | QS_ALLPOSTMESSAGE);
 
         ClearableMutexGuard aGuard( pInst->m_ClipboardChangedEventCountMutex );