The information in this article applies to:
SUMMARY
The OleActivate function will fail to launch an object linking and
embedding (OLE) server application for two reasons:
MORE INFORMATION
When a server application is invoked to edit a linked object, the
server must read the specified file as quickly as possible and as an
uninterrupted operation (without yielding control of the processor).
If the server yields control before it has read the linked object file
and registered it, the OleActivate function can fail.
blocking serverAnother way to handle yielding within the server is to set an internal global flag that indicates whether or not the server application is busy. If the server is busy, it returns the OLE_BUSY value from all method callback functions. To implement this technique, the server registers itself and the document (as indicated above), and sets the internal flag. When the OLE library calls the OLESERVER, OLESERVERDOC, or OLEOBJECT method, the server checks the global flag. If the flag is set, the server returns OLE_BUSY. Once the file is loaded, the server resets the global flag. Then the OLESERVER, OLESERVERDOC, and OLEOBJECT methods can perform their regular processing. Implementing blocking and unblocking is completely transparent to the user and to the client application. The function calls of the client will succeed when a server application is blocked. The OLE libraries queue all requests to the server application until the server unblocks itself. Returning OLE_BUSY allows the client application to inform the user that the server is not ready to process the request. This allows the client application to determine whether the user wants to cancel the application or to try again. Either procedure is acceptable. The author of the server application can choose the procedure deemed most appropriate. Additional query words: 1.00
Keywords : kbole kbprg kbOLE100 kbGrpCom kbDSupport |
Last Reviewed: October 26, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |