OLE Specification

From RISC OS
Revision as of 16:34, 28 January 2009 by Erik Groenhuis (talk | contribs) (Another removal of .txt from OLESpec)
Jump to navigationJump to 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 know 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 and 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

Detailed specification