The linked object feature of OLE Documents is built on top of the basic architecture for embedded objects, as described in earlier chapters. Whereas an embedded object stores all of its native data in the container's compound file directly, a linked object stores its native data somewhere else and provides the container with a moniker that refers to that other storage location. This moniker is then serialized in the compound document, providing the "link" between the document and the object's data. Cached presentations are also saved in the compound document exactly as they are for embeddings, in case the link becomes invalid.
Invalidating a link is not difficult in current file systems, in which files can move independently of one another without the operating system necessarily knowing of the event. Microsoft plans to provide the ability to track links between compound documents and the sources of object data so that when the source moves, OLE can automatically update the moniker inside a compound document in order to preserve the link.
This chapter deals primarily with the view of a linked object as seen by a container; in this situation, the object contributes the interfaces IExternalConnection and IOleLink alongside all the other embedded object interfaces. It is the presence of IOleLink that differentiates a linked object from an embedded one. Through this interface, a container can choose between automatic (hot) and manual (warm) links for a linked object, as well as update the object, change the source of the object's data (used to repair broken links), and intentionally break the link itself. All these functions are exposed to the user through the standard Links dialog box, provided in the OLE UI Library. Most of the work in implementing a linking container, as is illustrated in this chapter using Patron as an example, comes from the necessary support for this dialog box.
Of course, a container must have a way to create linked objects in the first place. It can do so any time that it has a moniker referring to a source of data. The container might have a moniker itself, or it can obtain one from the clipboard or by means of a drag-and-drop operation. (The moniker is serialized in a stream and identified with the CFSTR_LINKSOURCE format.) OLE provides API functions to create a linked object from a moniker or from the data available in a data object. Containers use both the Insert Object and Paste Special dialog boxes in order to give the user the means to create such linked objects.
Containers also provide a Show Objects command that outlines linked objects with a dashed line and embedded objects with a solid line, giving the user a way to see the types of objects in a compound document. In addition, containers also automatically update any linked objects in a document when that document is loaded to ensure that presentations are up to date. Once again, all of these features are demonstrated in the Patron example accompanying this chapter.