If anything is central to the idea of linked content objects in OLE Documents, it is a moniker that provides the link between what is stored in a compound document and the real object's data that exists somewhere else. A linked object, for the most part, appears to a container the same as an embedded object—it still maintains a cache, still requires its own storage object, and still makes use of the container's site. Because a linked object is so much like an embedded object, it is best to implement embedding support in a container or server first and then implement linking. Linking is mostly an extension of embedding.
There are two major differences between a linked object and an embedded object. The first is that a linked object has two additional interfaces. One is IExternalConnection (for linking to embedding support), and the other is IOleLink, through which the container can manipulate the moniker that defines the link. The second difference is that the object's native data does not exist in the compound document itself. Instead, the object's storage contains the serialized moniker that names an external location where that data does exist. This relationship is illustrated in Figure 20-1.
Figure 20-1.
The container, cache, and handler for a linked object still use the object's storage to store the cached presentations and the moniker that names the location of the object's native data.
The object's storage, like that for an embedded object, still contains all the cached presentations and other object information. Linking simply means that the object's native data is replaced with a serialized moniker.
The following sections look at the three primary parts of OLE Documents that make linking work. In the first we'll see where linked objects come from in the first place. Next we'll see the details of IOleLink and the standard Links dialog box in which the user can manipulate that link. Finally we'll look at issues surrounding link tracking.