OLE's Naming and Binding technology is centered around a type of object called the moniker, which acts as a symbol or a name for some other object. The purpose of this technology is to enable applications to use a wide variety of names in a polymorphic, and thus extensible, manner, keeping specific code for specific types of names out of those applications.
A moniker maintains persistent data that describes the name itself and provides the intelligence (code) that knows how to bind that name. These operations are encapsulated behind the interface IMoniker, whose BindToObject member resolves the moniker's name as an interface pointer to the named object, returning that pointer to whoever asked the moniker to bind itself. IMoniker itself is derived from IPersistStream, meaning that monikers know how to read and write their persistent data (their names) into a stream. Thus monikers are also called persistent, intelligent names.
Monikers can be created in many ways, either by the source of the object being named or by a client who wants to fabricate a name for some known object. OLE supplies five standard monikers: file, item, pointer, anti, and generic composite. The composite moniker is nothing more than a container for other monikers, but with it you can create arbitrarily complex names using the other simple monikers. Simple monikers themselves name only things like an entire file. It is also worthwhile at times to implement a custom moniker, which is simply an object that implements IMoniker structured inside a server and given a CLSID. Implementing IMoniker, a rather large interface, is nontrivial, but in this chapter we explore the purpose of its member functions.
Binding a composite moniker is the process of binding its constituent pieces in a right to left manner, thereby eliminating any extra overhead. Two optimizations, the running object table and the bind context, are available to improve binding performance. The server that supports linking to its objects through monikers must implement the necessary structures and interfaces to support the binding process of a composite as well as a single file moniker. This chapter demonstrates how this works to the level of complexity of a File!Item!Item moniker, which is a composite containing a file and two levels of items, whereby the composite as a whole names a specific piece of a compound file.
Finally, monikers can generate a display name from their persistent data (to show the user) as well as parse such a display name back into an appropriate moniker. These capabilities are also demonstrated in this chapter's samples.