If the server application needs to carry out a long operation and you do not want it to be interrupted by an OLE request, have the application call the OleBlockServer function, which instructs the server DLL to queue any OLE messages destined for the application. Then, when the application is ready to process these requests, call OleUnblockServer prior to GetMessage in your main message loop and in any message loop used to wait for a Release. OleUnblockServer causes all queued requests to be processed before GetMessage can retrieve the next message.
Implementing a blocking mechanism first requires that your application maintain a global flag indicating that it is ready to unblock. When the server application wants to block, it calls OleBlockServer. When it is ready to unblock, it sets its block flag to TRUE.
In the message loops, have the application call OleUnblockServer when the global flag is TRUE, and repeat until there are no more blocked requests, at which time the flag is set back to FALSE.
A typical case where a server would use OleBlockServer is when a modal dialog box appears. A modal dialog box has its own message-processing loop inside Windows, so any DDE messages going between the OLE libraries will cause calls to your server's callback functions. This may cause unwanted actions while a dialog box is displayed. To avoid this problem, block the server immediately before putting up a modal dialog box, thereby not allowing the server DLL to make any requests to the application until OleUnblockServer is called.
A server application can alternatively return OLE_BUSY from any function when it does not want to handle OLE requests. Unlike OleBlockServer, returning OLE_BUSY allows the server application to choose which requests to process and allows the user at the client application to decide whether to discontinue or retry the request.