OLE Specification


Revision as of 11:23, 7 February 2009 by FJG (Talk | contribs)
Jump to: navigation, search

The original OLESpec document (dated 14 Aug 1993) was widely distributed in its time, but is now rather difficult to find. There used to be a copy on Hensa, but that site has long gone. Some people have taken the trouble of keeping a copy and putting it on the web. There is a slightly mangled HTMLified version on the Pink Noise archive pages, and a text version on the private website of Erik Groenhuis. We could put a copy on this wiki if it could be confirmed that there is no copyright on this document. There is good hope, as in the Help system of Impression this text can be found under 'OLE':

The OLE system provided in Impression is open.  This means that it is not a proprietary 
scheme that is limited to only Computer Concepts' programs. It can work with data from a 
wide variety of applications and it is quite a simple matter for program writers to make their 
applications work with this scheme.

This suggests that the original documents can be freely distributed.

Unfortunately the original document is rather vague on many points. Apart from typos it has blatant errors where the word 'client' is used where 'server' was intended and vice versa. A programmer will find it hard going, trying to base an application on the information given.

Information can also be found in a StrongHelp manual that accompanies Elixir 8 for Doctor Wimp (see the Elixirs.zip file there). That package includes support libraries for writing both an OLE server and an OLE client using Doctor Wimp.

Summary of the protocol

A server makes it known to the system that it supplies an OLE service for a particular file type by setting an environment variable. A client that wishes to start an OLE session reads that variable to find out the necessary details of the server. If the server is not yet running, the client can start the server.

The client saves the data it wants to have edited on disk, and broadcasts an OLEOpenSession message. If the server is running properly it will intercept the broadcast, and send an OLEOpenSessionAck message back to the client. An OLE session is now in progress.

The server reads the file from disk and offers it to the user for editing. Whenever the file on disk is changed, either because the user is finished with it or through intermediate saves, the server should send an OLEFileChanged message to the client. The client should then read back the file and integrate the data in its application.

Whenever a server throws data away, e.g. because the user clicked the Close Window button on the document (and also tells the server to discard the changes made), the server should send an OLECloseSession message to the client. The client then knows it need not expect any further OLEFileChanged messages for this session.

A client can also send an OLECloseSession message whenever it wants to close a session from its end. This can happen e.g. when the user of the client application closes the document for which the OLE session was required.

Both the client and the server should broadcast OLECloseSession messages whenever they are shutting down

The OLESupport module

For many file types an editor is available (e.g. Draw), but that editor does not support the OLE protocol. To help the use of OLE for these file types, Computer Concepts developed the OLESupport module. This module can pretend to be a server for a given file type. On one side, it communicates with the client through OLE messages. On the other side, it invokes the editor on the temporary file, watches that file for changes, and notices when the file is closed.

This module is so effective that it is now hardly worth the effort to implement OLE server code in existing or new editors. To illustrate: Computer Concepts themselves use the OLESupport module to let Impression communicate with its own Tablemate table editor, rather than implement OLE server code in Tablemate.

The main drawback seems to be that the module can not prevent the user from saving the edited data to a different file (e.g. by dragging from the Save As box to a filer window). The change in data will then not be reported to the OLE client.

The module was distributed widely, and is usually already present in the !Boot structure.

Detailed specification

Personal tools