How To Use SendMessageTimeout() in a Multithreaded Application

MORE INFORMATION

This article uses the following scenario to illustrate the behavior of this function:

Suppose that Win1 and Win2 are created by the same application and that the following code is included in their window procedures:

   <WindowProc for window Win1>
      ...
      case <xxx>:
         ...
         SendMessageTimeout(      hWnd2,   // window handle
                              WM_USER+1,   // message to send
                                 wParam,   // first message parameter
                                 lParam,   // second message parameter
                            SMTO_NORMAL,   // flag *
                                    100,   // timeout (in milliseconds)
                                   &ret ); // return value
        ...
         break;

      case WM_USER+2:
        <time-consuming procedure>
         break;

* Note that the SMTO_NORMAL flag indicates that the calling thread can
process other requests while waiting for the API to return.

   <WindowProc for window Win2>
      ...
      case WM_USER+1:
         ...
         SendMessage(     hWnd1,    // window handle
                      WM_USER+2,    // message to send
                         wParam,    // first message parameter
                         lParam );  // second message parameter
         OtherStuff();
         ...
         break;
				

If Win1 executes this SendMessageTimeout() and Win2 uses SendMessage() to send a message to Win1, Win1 can process the message because SMTO_NORMAL was specified. If the SendMessageTimeout() expires while the execution is currently in the window procedure for Win1, the state of the system will depend on who owns the windows.

If both windows were created by the same thread, the timeout is not used and the process proceeds exactly as if SendMessage() was being used. If the windows are owned by different threads, the results can be unpredictable, because the timeout is restarted whenever a message or some other system event is received and processed. In other words, the receipt by Win1 of WM_USER+2 causes the timeout to restart after the message is processed. If the function executed by Win2, OtherStuff(), then uses up more than 100 milliseconds without awakening the thread that created Win1, the original SendMessageTimeout() will timeout and return. The OtherStuff() function continues to completion but any value that was to be returned to Win1 will be lost. Note that the code paths will always complete.