OLE Concepts and Requirements Overview (86008)

MORE INFORMATION

OLECLI.DLL -- The OLE Client Library

OLECLI.DLL, the OLE client library in the Microsoft Windows environment, provides services to simplify an OLE client application. Bidirectional communication takes place between a client application and the OLE client library. A client application calls functions in the client library to perform OLE tasks such as object creation, rendering, loading, and saving. The client library sends status information to the application by calling an application-defined callback function. The status data the library passes to the client's callback function includes notification that an object has been changed, renamed, saved, or closed by an OLE server application.

OLESVR.DLL -- The OLE Server Library

OLESVR.DLL, the OLE server library, provides services for an OLE server application. Bidirectional communication takes place between a server application and the OLE server library. A server application calls functions in the server library to register itself as available, or to revoke its availability. It also calls server library functions to indicate when it saves or renames a document. The server library conveys information to the server application through a set of 27 application-defined callback functions. Each of the server application's callback functions, which are commonly called methods, is called to request that the server perform a specific action, or to inform it that a specific event has occurred.

Object Handlers

An end-user is typically concerned only with two types of OLE applications: client applications and server applications. However, an application developer must also be aware of a third type of OLE module called an object handler. An object handler is a dynamic-link library (DLL) that can be conceptualized as a limited-function server application. An object handler contains functions required to support a server application's object classes. For example, when a client application invokes an object's verb, this call can be processed by an object handler that loads into memory, processes the call, and unloads from memory without any assistance from the main server application. An object handler provides an efficient way to manage objects, because a handler is typically small and can be loaded and unloaded more efficiently than an (often large) full-function server application. An object handler is implemented using the OLE server library just like a fully-functioned server application.

Using VTBLs

As noted above, communication from the OLE client library to a client application, and from the OLE server library to a server application, takes place through application-defined callback functions. During the initialization of a client or server application, it calls the appropriate library with a pointer to a VTBL data structure. The library uses the pointers in the VTBL to call the application's callback functions.

For example, one of the VTBLs that a server application provides to the OLE server library is called an OLESERVERVTBL. The server application fills the OLESERVERVTBL structure with pointers to six callback functions that implement the Create, CreateFromTemplate, Edit, Exit, Open, and Release methods. Once the server application passes the initialized VTBL to the server library, the library can call any of the six methods just by dereferencing pointers in the VTBL. Note that using a VTBL allows the OLE libraries to call an application-defined function that implements a method independent of the function's name.

To programmers familiar with the C++ language, the VTBL concept may seem similar to the C++ virtual method concept. In fact, VTBLs and virtual methods are closely related. A VTBL allows the OLE libraries to specify the methods that a client or server application must implement, while allowing the implementation of each method to be defined differently for each object class.

Inter-library Communication

In the initial implementation of the OLE libraries, provided with version 3.1 of the Microsoft Windows Software Development Kit (SDK), the libraries communicate with each other using the dynamic data exchange (DDE) messaging protocol. The client and server libraries send each other a standard set of OLE commands using WM_DDE_EXECUTE messages. This implementation of the OLE libraries does not use the Dynamic Data Exchange Management Library (DDEML) developed for Windows version 3.1 because the DDEML and the OLE libraries were developed in parallel. Future versions of the OLE libraries may use the DDEML or another interprocess communication mechanism.

The inter-library communication protocol used by the OLE libraries is hidden by the libraries themselves and it should not affect the design of an OLE client or server application.

The Shell Library

Many OLE applications also use a third library, SHELL.DLL. The shell library provides API functions that allow an application to read and modify the Windows registration database. The registration database contains information about the OLE servers installed on the system, and the object classes and verbs that each supports. The shell library also provides support for drag-and-drop manipulation of files using the Windows File Manager. If an OLE client implements drag-and-drop support, a file may be dragged from the File Manager and dropped on a document in a client application to embed the file in the document.

Placing an OLE Object on the Clipboard

The presentation format used to display an object specifies the object's appearance. When a server application places an object on the clipboard, it supplies one or more graphical representations of the object. These representations can include the metafile (CF_METAFILEPICT) format, the device-dependent bitmap (CF_BITMAP) format, or the device-independent bitmap (CF_DIB) format. When the user pastes an object into a container document in a client application, the OLE libraries use one of these presentation formats to display the object. Because a bitmap or a metafile commonly changes appearance when it is resized, the appearance of an object may vary depending on the presentation format used to display the object.

An embedded object is stored on the clipboard in the OwnerLink format, the Native format, and one of the three presentation formats described above (CF_METAFILEPICT, CF_BITMAP, or CF_DIB). Each presentation and predefined Windows format is represented by a named constant in the WINDOWS.H header file included with the SDK. However, the OwnerLink and Native formats, which are used by every OLE application, are not defined in WINDOWS.H. Each OLE application must call the RegisterClipboardFormat function to register the OwnerLink and Native formats with Windows.