This type of subroutine occurs with window procedures that are invoked synchronously via a WinSendMsg() call. The message is processed, and the return code from the window procedure is routed to the calling routine by Presentation Manager. The calling routine then completes its execution. If any queued messages are generated by the called window procedure or subroutine, these messages are not processed until the calling routine completes its execution and the application issues its next WinGetMsg() call. This is so, even if the called window procedure or subroutine executes in a separate thread.
This type of invocation should be used for access to another application object, where the function to be performed must be executed synchronously and the result returned directly to the caller. However, use of the WinSendMsg() call in preference to the WinPostMsg() call for communication between objects may result in messages being processed out of order due to the application pre-empting the normal order of execution determined by the message queue. The WinSendMsg() function should thus be used with care. The use of this call may also extend the time interval between successive WinGetMsg() calls to Presentation Manager, thus decreasing the application's responsiveness to user interaction.