The first way in which we can obtain linking information is to use the Insert Object dialog box, provided we do not specify IOF_DISABLELINK. Chapter 17's version of Patron included this flag, so we remove it now. If the user selects the Link check box and provides a filename, the dwFlags field of the OLEUIINSERTOBJECT structure, on return from OleUIInsertObject, will contain the value IOF_CHECKLINK. From this we know to call OleCreateLinkToFile as opposed to OleCreateFromFile as we did in Chapter 17. In this case, Patron passes the flag TENANTTYPE_LINKEDFILE along with the filename all the way down to CTenant::Create (TENANT.CPP), which then calls OleCreateLinkToFile:
//In CTenant::Create
switch (tType)
{
[Other cases]
case TENANTTYPE_LINKEDFILE:
hr=OleCreateLinkToFile((LPTSTR)pvType, IID_IUnknown
, OLERENDER_DRAW, NULL, NULL, m_pIStorage
, (PPVOID)&pObj);
break;
§
}
As with OleCreateFromFile, the first argument to OleCreateLinkToFile is the filename in question. In both cases, OLE creates a file moniker and attempts to bind it so that the server associated with the file must again implement IPersistFile to support this operation. If that fails, both functions will attempt to create a package object whose display is always an icon. Whereas OleCreateFromFile makes a package with the contents of the entire file, OleCreateLinkFromFile creates a package with just the name of the file inside. This is embedding and linking in its most primeval stages. Keep in mind, however, that OleCreateLinkFromFile will create an embedded package that stores the linked filename inside it. That is, the container will not see the package itself as a link. But a link of some sort is still involved, in the form of an embedded filename.
You may remember from Chapter 17 that a container does not initially activate an object created with OleCreateFromFile. The same applies to objects created with OleCreateLinkToFile. Only blank objects created with OleCreate should be activated immediately.