Keeping the OleActivate Function from Failing

 Last reviewed: February 17, 1995
Article ID: Q83553
The information in this article applies to:
  • Microsoft OLE version 1.0

SUMMARY

The OleActivate function will fail to launch an object linking and embedding (OLE) server application for two reasons:

  • The server is not installed in a directory listed in the MS-DOS PATH environment variable or in the Windows directory.
  • The server for a particular class of object is not registered properly or is not available.

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.

If the server application must yield the processor while reading the file, it must first register both itself and the unread file with the OLE library. The OleRegisterServer and OleRegisterServerDoc functions are provided for this purpose. Once the server is registered, the server calls the OleBlockServer function to prevent the OLE library from calling the server until the file has been read. Calling the OleUnblockServer function signals that the file has been read and that the server is ready. For more information on blocking and unblocking OLE server applications, query on the following words in the Microsoft Knowledge Base: 

   blocking server
Another 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 reference words: 1.00
KBCategory: kbole kbprg
KBSubcategory: LeOneSvr

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: February 17, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.