After you copy link-source data to the clipboard, containers can create a linked object from it.1 After all, it only takes a moniker to create the linked object. If you copy the link-source data now and try to activate the object, your server will be launched, provided GetClassFile can map your file moniker contents to your CLSID. Unfortunately, activation will not succeed because we haven't implemented IPersistFile yet. That is the next step, and the implementation is different from the ones we saw in Chapters 8, 9, and even 14. (In Chapter 14, Cosmo implemented IPersistFile support for accessing a file as an automation object.) Here we implement this interface as part of Cosmo's CFigure class alongside IOleObject and IDataObject. So after we've loaded the file, we'll be queried for IOleObject. When we've returned that interface, we should see a call to IOleObject::DoVerb, in which we activate our user interface.
Because we're editing a linked object, however, we do not—repeat, do not—modify the server's user interface when we show the window (as we did for embeddings in Chapter 18). With linked objects, end users need to know that they are working with a file, so they need File menu commands through which they can save or rename the file. In Chapter 18, we only switched the user interface around from within IOleObject::SetHostNames. Well, that function is never called for a linked object in a local server, so we never have to bother the UI. No problem!
1 Including OLE 1 containers, which see your moniker as OLE 1 link-source data. |