ID Number: Q83553
3.10
WINDOWS
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:
prod(winsdk) and 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: 3.10