This is the case for window procedures invoked in the standard way using a WinPostMsg() call from another window or using the WinDispatchMsg() function from the application's main routine. In this case the message is processed, and any messages generated during execution are posted to the appropriate queue, but the return code from the window procedure is passed only to Presentation Manager, and does not reach the calling window procedure. For this reason, it is important that any message that requires acknowledgement be handled in such a way that the window procedure generates a message that is routed to the calling window, and that contains the required acknowledgement.
This type of invocation should be used for access to other application objects, where the function to be performed need not be performed synchronously, and where acknowledgement or completion of the processing may be indicated by a subsequent message posted to the caller.
Note that this should be the default method of invocation for window procedures, since the asynchronous nature of the processing allows the application to maintain the highest level of responsiveness to user interaction.
Note also that a window may receive messages from a number of sources. This allows a window to service requests from a number of other windows, in accordance with a client-server architecture. This concept is discussed further in Client-Server Applications.