Summary

OLE Documents is a standard protocol for the creation, exchange, and management of blocks of unstructured data, which are called compound document content objects, or simply content objects for short. A container that conforms to OLE Documents can incorporate any content object into a compound document, regardless of the data contained in that object or the source of that object. A server that supplies such objects also conforms to OLE Documents so that those objects can be stored in any other container's compound document. As a whole, OLE Documents is designed to eliminate a number of end-user difficulties in the creation and management of compound documents, such as locating the necessary server for a particular type of content and moving data between source and container with a high degree of fidelity. Through the standard Insert Object dialog box, a user can directly choose the type of content to create—OLE Documents will locate the correct server to run, and it will connect the container and server. After an object is created, the user can choose to "activate" the object by selecting an object "verb" or "action." This choice automatically runs the correct server for performing the action.

Content objects can exist in a compound document two ways: they can be embedded or linked. An embedded content object is one whose native data and cached graphical presentations of that data are stored entirely in the compound document itself. Where the document goes, the object's data goes also. A linked object is one whose native data resides in another location outside the document, although it still carries cached presentations in the compound document. A linked object manages a moniker to refer to the outside location of its native data, but it's possible that such a link can be broken.

In either case, the basic set of interfaces for an embedded object include IDataObject, IViewObject2, IPersistStorage, IOleCache2 (optionally IOleCacheControl), IRunnableObject, and the mainstay of OLE Documents, IOleObject. These interfaces are the means by which a container sees an embedded object. (Linked objects add the interface IOleLink.) Depending on how an object is implemented, it might or might not need to support all these interfaces. For each object, a container has to provide certain services through a site object itself, where this site implements the interfaces IAdviseSink and IOleClientSite. Most of the member functions in these interfaces deal with notifications of various events that occur during the lifetime of an object.

OLE Documents adds a number of additional states to those already known. Besides being passive or loaded, an object can also be running, which means its server is fully loaded and is being used for all necessary services; or it can be active, which means the object's user interface is available so that the user can directly edit or manipulate the object. When the object is being serviced by an in-process server, the difference between and loaded and running states is minimal. The difference is more important for objects from local servers; in this case, the local server is not in memory unless the object is in the running state. When such a local object is merely loaded, there is always an in-process handler in memory for it, which might be either a custom handler or an instance of the default handler, the latter of which provides generic services for all objects in the absence of a specific custom handler.

This chapter details the architecture of OLE Documents, the role of the interfaces with all the different objects involved, and the information in the registry that pertains specifically to this protocol. The latter half of this chapter focuses on the step-by-step implementation of an embedding container, which is mostly concerned with various pieces of user interface such as the Insert Object and Convert dialogs, shading a site when its object has been activated, dealing with the clipboard and drag and drop, and handling different display aspects for objects. These features are added to the Patron sample, which now becomes capable of managing embedded objects in a compound document. This chapter is thus the first step in the full treatment of OLE Documents, which continues through Chapter 23 and builds a foundation for OLE Controls in Chapter 24.