Creating and Using Standard Monikers: LinkUser

Now that we understand what monikers are and how they are used to name objects and link to those objects, we can look at monikers in action through three samples—LinkSource, LinkUser, and IDescription.

• LinkSource (CHAP09\LINKSRC) has two modes of operation. When it is run stand-alone, you will see a window and a menu from which you can create a file named GOOP.LKS (for lack of a better name) that is bindable through a file moniker. The rest of LinkSource exists to support binding File, File!Item, and File!Item!Item monikers that identify the file or pieces within that file. (The pieces are substorages from the root, or substorages of substorages.)
• LinkUser (CHAP09\LINKUSER) manages three monikers: a file moniker to the LinkSource file (GOOP.LKS), a File!Item moniker naming the Object 2 piece of that file, and a File!Item!Item moniker naming Sub-Object 3 in Object 2 of that file. LinkUser shows the display name of each moniker in a list box; double-clicking on that item (or using the Link/Show Description menu item) attempts to bind the moniker by asking for IDescription, through which LinkUser then asks for a piece of descriptive text from the object. You can also ask LinkUser to take that display name and attempt to parse it into a moniker (the Link/Parse Display Name And Bind menu item) and then bind that moniker.
• IDescription (CHAP09\IDESCIP) is a custom interface that allows us to ask an object for a piece of descriptive text through its GetText member function. This simple interface has the same semantics as that described earlier in this chapter.

In this section, we'll use LinkUser to look at the client side of monikers. The next section will examine LinkSource in more detail. Because IDescription is simply an IDL file for the custom interface, it contains nothing that we didn't already see in Chapter 6. However, be sure to compile and register both LinkSource and IDescription before running LinkUser, or else nothing will work. If you forget, you'll have a good opportunity to see what will happen in the absence of the link-source server or the interface marshaler.

These three samples work together to illustrate the entire binding process as well as to show parsing. From LinkUser's point of view (the client's, that is), these processes are very simple: binding is encapsulated entirely within BindMoniker and IMoniker::BindToObject, and parsing is executed entirely within MkParseDisplayName. Most of LinkUser, in fact, is code that calls these functions and does something with whatever comes back from them. But the first major issue is how LinkUser comes into the monikers in the first place. After we know that, we can examine its code to bind those monikers and then the code to parse display names.