Microsoft KB Archive/106716

{|
 * width="100%"|

HOWTO: Use SendMessageTimeout in a Multithreaded Application

 * }

Q106716

-

The information in this article applies to:


 * Microsoft Win32 Software Development Kit (SDK)

-

SUMMARY
SendMessageTimeout is new to the Win32 application programming interface (API). The function sends a message to a window and does not return until either the window procedure processes the message or the timeout occurs.

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:

   ...     case : ...        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:  break;

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

 ...     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.

Additional query words:

Keywords : kbOSWinNT350 kbOSWinNT351 kbOSWinNT400 kbOSWin2000 kbSDKWin32 kbGrpDSUser kbOSWin95 kbOSWin98 kbWndw kbWndwMsg

Issue type : kbhowto

Technology : kbWin32SDKSearch kbAudDeveloper kbSDKSearch kbWin32sSearch