ID: Q106716
The information in this article applies to:
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.
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.
Additional query words:
Keywords : kbNTOS350 kbNTOS351 kbNTOS400 kbWinOS2000 kbGrpUser kbWinOS95 kbWinOS98 kbWndw kbWndwMsg
Issue type : kbhowto
Last Reviewed: January 2, 1999