Jon Singer
Created: May 2, 1992
ABSTRACT
This article provides a general overview of object linking and embedding (OLE). It explains what OLE is, discusses why it is important, and provides suggestions for implementing OLE successfully in your applications.
In his November 1990 COMDEX keynote speech, Microsoft Chairman and CEO Bill Gates demonstrated an idea he calls “Information at your Fingertips”—a vision of document-centered, task-oriented computing that allows users to handle pieces of information in a smooth and efficient manner.
Object linking and embedding (OLE) is part of that vision. OLE lets users work with information in essentially any data format and removes the cobwebs and complications from the process of including different types of information in documents. Users can edit data without having to know what a particular application is, where it is located, or how it can be connected to their current work.
OLE capabilities represent a considerable advance in ease-of-use and productivity. Users can now concentrate on the task at hand rather than wondering whether a drawing or table is up to date or searching for its source file.
Adding OLE-awareness and OLE capabilities to existing applications and building OLE into new applications are worthwhile and important tasks. However, adding OLE is not a trivial process; it involves many issues, considerations, and pitfalls. This article covers the major issues involved and provides some helpful suggestions to guide you on your way.
An OLE object is any set of data—from a single spreadsheet cell to an entire document or file—that a user can display and manipulate. When an object is embedded into (or linked to) a document, it maintains an association with the application that produced it. This is one crucial way in which OLE differs from the original cut-copy-paste metaphor.
When an object is embedded into a document, the data that constitutes the object is placed directly in the document file and becomes part of it, along with information about the application that created the object. For example, if a drawing is embedded in a text file, the drawing data is saved as part of the text file. The name of the application that created the drawing is also saved in the file.
Figure 1 shows how the data for embedded objects becomes part of the document file.
Figure 1. A Document with Embedded Objects
When users want to edit an object (the drawing, for example), they simply open the object. The appropriate application (the server application) comes up with the ready-to-edit drawing in a window. When the user finishes editing the object, the server application passes the updated object data back to the application that owns the entire document (the client application) for display. Thus, users can change an object even if they don’t know which application created the object; in fact, they may not even be aware that they are working with an object.
A linked object differs from an embedded object in the way it is stored. When a document links an object instead of embedding it, the document saves only a link to the data and some presentation information. The data itself remains elsewhere. To the user, a linked object looks the same as an embedded object: The user can double-click the object to start the server application, edit the object, and return to the client document with updated information. The difference between a linked object and an embedded object is that when the user double-clicks a linked object, the server application opens the original file that contains the object. The object itself is never placed into the client document. Instead, the client document contains a link to the original file and uses presentation data to display the object.
An example of a linked object is a range of cells created in a spreadsheet application. In this case, the client document contains a link that specifies the full path to the file that contains the cells and the range of cells to be included. The same cells or other cells from the spreadsheet can also be used in a memo or in a financial report. When the user updates the information in the spreadsheet, either directly or by running the spreadsheet application as a server from a client document containing the cells, all of the linked documents can be updated easily. This ensures that all documents using the particular spreadsheet are synchronized and are equally up to date. Figure 2 illustrates the document shown in Figure 1; in this version, however, the objects are linked instead of being embedded in the client document. A linked object is typically much smaller than an embedded object (compare the schematic views in Figures 1 and 2). Thus, another advantage of links is to conserve storage. This is especially important with large illustrations.
Figure 2. A Document with Linked Objects
A simple document may contain (for example) drawings, but the user cannot edit these drawings directly. Double-clicking a drawing has no effect because it is no longer connected to the application that created it. The documents in Figures 1 and 2, by contrast, are compound documents; they contain additional information that lets OLE find the application that created an object, so the user can work with the object directly.
A compound document uses the facilities of OLE-aware applications to manipulate the different kinds of data it displays. Essentially, you can incorporate any data format into a compound document, and OLE can handle new data formats easily, as they are defined. The user need not know which data formats are compatible or how to find and start the applications that created the data.
Figure 3 shows our document once again. This time the drawing is an embedded object and the spreadsheet cells are linked for easy updating.
Figure 3. A Compound Document with Linked and Embedded Objects
The compound document that receives the data is also called the client application document, and the worksheet (the source of the data) is called the server application document.
An OLE client is an application (with associated documents) that accepts links and/or embedded objects from other applications and documents.
An OLE server is an application (with associated files, in the case of linked objects) that provides data for embedding and/or linking and that allows users to edit the objects. Some servers also allow other actions (play, stop, rewind, and so on), depending on the object class they handle.
An application can be both a client and a server. A word-processing application, for example, can accept data from a spreadsheet and can provide text for a slide presentation. Some applications (for example, a simple voice annotator) are more likely to be used as servers. A voice-note or an equation can easily be embedded into an electronic mail memo, but in most cases an equation has no particular reason to find itself inside a voice-note.
You can also create mini-servers for the MicrosoftÒ WindowsÔ version 3.0 or 3.1 graphical environment. Mini-servers are small applications that do not run in stand-alone mode, but are invoked only to work with embedded objects. (Mini-servers do not work with linked objects.)
Windows version 3.1 contains a special application called the Packager (PACKAGER.EXE) that puts an OLE “wrapper” around an object. For example, the Packager can encapsulate a file to be embedded into an electronic mail message. An object that has been wrapped with the Packager has a representative icon selected by the user. Double-clicking the icon causes OLE to “unwrap” the package. The Packager can encapsulate files, command lines, Clipboard contents, and objects.
Servers and mini-servers must reside on the user’s machine. Files that contain linked data can reside on the network.
The types of actions a user can perform on an object are called verbs. The nature of an object determines the actions a user can perform on it. Typical verbs are Edit, Play, and Run.
The most typical use of some objects (for example, voice annotations or animated scripts) is to play or to run them. When the user double-clicks such an object, the appropriate application starts and runs or plays the object. For these objects, a verb like Play or Run is the primary verb, and Edit is the secondary verb.
The most typical use of other objects (for example, text, equations, and spreadsheet cells) is to edit them. For these objects, the primary verb is Edit.
Client applications tell the server application to execute the primary verb when the user double-clicks an object. Many objects support only one verb. For example, an object created by a text editor usually supports only Edit.
The meaning of a particular verb is completely determined by the server application. A user can invoke an object’s subsidiary verbs, if any, by using the Edit Class-Name Object menu item and choosing a verb from the submenu displayed. If an object supports only one verb, that verb is used automatically when the user chooses the Edit Object menu item. For more information on this subject, see Chapter 9 of The Windows Interface: An Application Design Guide included in the Windows version 3.1 Software Development Kit (SDK).
Object linking and embedding offers the following benefits:
Applications can specialize in performing one job very well. A drawing application that implements OLE, for example, need not have text-editing capabilities because users can place text into the drawing and edit the text using any text editor that supports OLE.
Applications are automatically extensible for future data formats because the client document does not care about the content of an object.
Users can concentrate on the task they are performing instead of being concerned with the applications required to complete the task.
Files can be kept compact because linking allows a file to use an object without having to store that object’s data.
Linked objects can be updated dynamically.
Users can print or transmit documents without using the application that originally produced the document.
Future implementations of this protocol can take advantage of a variety of object types. Linked and embedded objects can support animated drawings, executable macro scripts, hypertext, annotations, and other similar features.
OLE consists of a set of dynamic link libraries (DLLs) and associated code included in the Windows version 3.1 SDK. The SDK also provides a sample server application and a sample client application.
Testing OLE functionality is not a trivial task. OLE is still relatively new, so OLE implementations vary in their accuracy and completeness. You should test your OLE implementation using the sample applications included in the SDK.
OLE has three libraries—OLECLI.DLL, OLESVR.DLL, and SHELL.DLL:
OLECLI.DLL contains functions that client applications can use to send information to server applications. It also notifies client applications through a callback mechanism.
OLESVR.DLL contains functions used by server applications. It also calls exported server methods to request actions from the server application.
SHELL.DLL contains functions for manipulating the system registration database (see the next section) and functions for the Windows version 3.1 drag/drop interface.
Each server application must register itself with the system database using functions from the SHELL library. When a server application runs, it typically checks the database to see whether it is registered. If not, it registers itself in the database and specifies the object classes that it handles and the verbs appropriate to those objects.
You may need to check and modify the database while you are debugging your application. A special application in the SDK called REGEDIT helps you with these tasks.
Callback functions are central to the way OLE works; OLE applications share this feature with other Windows-based applications. Callbacks are implemented through virtual table structures that contain far pointers to appropriate callback functions.
Client applications use two virtual tables:
OLECLIENTVTBL
OLESTREAMVTBL
Server applications use three virtual tables:
OLESERVERVTBL
OLESERVERDOCVTBL
OLEOBJECTVTBL
Figure 4 shows the communication routes in OLE.
Figure 4. Communication Paths in OLE
You can observe at least two levels of communication: Both clients and servers call application programming interface (API) functions in the DLLs, and the DLLs use callback functions in the client and server. The two DLLs communicate directly with each other through dynamic data exchange (DDE) conversations.
Because OLE operates by means of DDE conversations, you could implement some of the foundations yourself. PLEASE DON’T! Future versions of OLE may use a different protocol, requiring you to rewrite a large amount of difficult code. Let the OLE libraries and the OLE infrastructure do the work for you!
An OLE client application must be able to create an object for embedding or a link from Clipboard contents. Therefore, an OLE server application must put more information on the Clipboard than a non-OLE application does.
When you add OLE to an application, you must change the application’s Clipboard handling routines and its user interface. The user interface changes are described in Chapter 9 of The Windows Interface: An Application Design Guide.
Some servers may produce objects that can only be embedded; others may produce objects that can only be linked. A general format is used to produce objects that can be embedded, linked, or pasted into the document (if they are in a compatible data format) without involving OLE.
OLE uses four Clipboard formats:
Native data
OwnerLink data
ObjectLink data
Presentation formats
Native data represents the server’s own internal format.
The OwnerLink format describes an embedded object, and the ObjectLink format describes a linked object. The minimum information required to create a linked object is its ObjectLink data and a presentation format. OwnerLink and ObjectLink formats follow a structural convention that consists of the object class name, the document name (OwnerLink) or full path to the document file (ObjectLink), and the individual object name assigned by the server application.
The object class name is the name of a registered class of objects handled by the server application. In the OwnerLink format, the document and object names identify the information contained in the object by its location and extent.
In the ObjectLink format, the document name field must contain a full path to the linked file. This allows the OLESVR library to pass that file name back to the server when a client attempts to edit a linked object. The object name field specifies the information in that file to select when the user opens the linked object for editing. (For example, if the linked information comes from a spreadsheet, this field usually specifies a range of cells.)
The standard ordering for the formats that an OLE server puts onto the Clipboard is as follows:
Any special (private) data supported by the application
The application’s native data
OwnerLink data
CF_METAFILEPICT
CF_BITMAP
ObjectLink data (see note below)
Any other standard Clipboard format(s) supported by the application
In some cases, items from this list may not show up. For example, a link-only server may put only the ObjectLink data and graphic representation formats onto the Clipboard.
Note:
ObjectLink data should be put on the Clipboard only if the server has a file name to put into the format, and only if the data is being copied. (A link cannot be created if there is no file or if the data has been cut; the ObjectLink format should be omitted in those cases.)
When a link exists in one compound document, it can be extended to other documents with Copy and Paste. This creates a new copy of the original link to the source document. If the user chooses Copy and then Paste Link, however, OLE creates a new link that points back to the compound document; this is not the same as copying the original link. To restate this important distinction: If the user copies a linked object and then chooses Paste, OLE creates a new copy of the same link referring back to the original file. If the user copies a linked object and then chooses Paste Link, the new compound document receives a link to the old compound document, which in turn has a link to the original file.
Links can be moved using Cut and Paste, exactly like other Clipboard objects.
Embedded objects can be copied and moved like other Clipboard objects.
OLE introduces some user interface changes in the way applications handle copying and pasting. These are discussed in detail in Chapter 9 of The Windows Interface: An Application Design Guide included with the Windows SDK.
Programs that can function as OLE servers must produce a graphic representation of their data. Support of bitmaps and metafiles is required in most cases.
Because the OLE DLLs express all dimensions in MM_HIMETRIC units, your application must support this mapping mode and may need to convert to and from MM_HIMETRIC units.
Stand-alone OLE servers must support various Clipboard data formats, including the OLE-specific formats discussed above and the standard non-OLE formats that any program must support.
Programs must allocate memory for Clipboard formats and other OLE structures.
Some menu items change, depending upon circumstances. Applications must be able to change these as necessary.
This section discusses some important things to bear in mind when you implement OLE.
Certain distinctions are central to OLE or to your understanding of OLE. Some of these distinctions are fairly obvious; others are less so.
The distinction between:
What an application looks like to the user
What it looks like to the developer
appears obvious but actually has several levels. The developer can be a user, but even when wearing a user’s hat, a developer has a different understanding of the program and a different perspective on what the program is doing. Most users know nothing of DLLs or callback functions and are entirely happy with this state of affairs. Their interactions with software are typically on the “black-box” level: either it does what they want or it doesn’t.
The effects of this perspective difference can show up if you, the developer, try to do your own user testing.
The developer must also distinguish between:
A document
A file
An instance
In a closely related distinction, “multiple instance” in OLE is very different from multiple document interface (MDI).
Some developers find adding OLE-awareness to an existing application as easy as building it in, possibly even easier. Others find building OLE in easier than adding it. This suggests that the difference is not inherent in OLE but depends on the developer’s approach.
OLE can change independently of Windows, so you should be prepared to modify or upgrade your OLE code without necessarily changing the rest of your application. For this reason, we suggest that you keep the OLE code separate from other code in your application.
When you debug your work, it is important to be able to start the application in the debugger.
Some parts of OLE are optional; they generally enhance an application’s abilities. For example, if a server supports the OleSetData and OleRequestData functions (available to client applications from the OLECLI library), it allows a client that understands an object’s native data format to set or retrieve that object’s data.
Include version number data structures in your application and version numbers in the files that your application generates. Without version numbers, a server could crash when attempting to edit a data structure from a different version of the same application.
Put a unique identifier in the data structure so that other applications can recognize data generated by your application. This lets them know which conversion utility to use, if conversion becomes necessary.
Isolate the OLE parts of your application from the non-OLE parts. Thus, if OLE changes, you don’t have to sift through everything to find the parts of your code that need to be changed.
Future versions of OLE will require any server application to provide a graphic representation of its native data in a metafile (and possibly in a bitmap as well). Put these capabilities into your application early on to save yourself time and trouble later. When you create a metafile, use the MM_ANISOTROPIC mapping mode so that the metafile will scale properly. Specify the units of the metafile in MM_HIMETRIC units or convert your own units to and from MM_HIMETRIC units. These are the units that OLE uses for expressing all dimensions.
Use TrueTypeÒ fonts if you can, particularly if you are targeting Windows version 3.1.
Implement the Edit Paste Special command unless there are pressing reasons not to.
Avoid implementing link-only servers unless you have good reason to do so. Let the user decide what to do with the data.
Avoid implementing the DDE part of OLE yourself. OLE may no longer use DDE in future versions.
OLE is an important “next step” in the development of personal computing and is part of the foundation on which future developments are built.
Although careful attention to detail is necessary, you can implement OLE in a new or existing application reasonably quickly and easily. Following a step-by-step approach makes it possible to check your code at intermediate steps and simplifies debugging.