IMoniker - URL Moniker Implementation

The URL moniker implementation of IMoniker is found on a URL moniker object, which also supports IUnknown and IAsyncMoniker. The IMoniker interface inherits its definition from IPersistStream as well as IUnknown and IPersistStream inherits from IPersist. Thus, the IMoniker implementation includes support for IPersistStream and IPersist.

The IAsyncMoniker interface is simply IUnknown (there are no additional methods). It is is used to allow clients to determine if a moniker supports asynchronous binding.

To get a pointer to the IMoniker interface on this object, call the CreateURLMoniker function.

Note The current URL Moniker implementation of IMoniker does not support asynchronous storage. Future implementations will do so.

When to Use

If you’re a moniker client (that is, you’re using a moniker to get an interface pointer to an object), you typically don’t need to know the class of the moniker you’re using; you simply call methods using an IMoniker interface pointer.

If you’re a moniker provider (that is, you’re handing out monikers that identify your objects to make them accessible to moniker clients), you must use item monikers if the objects you’re identifying are contained within another object and can be individually identified using a string. You’ll also need to use another type of moniker (for example, file monikers) in order to identify the container object.

To use item monikers, you must use the CreateItemMoniker function to create the monikers. To allow your objects to be loaded when an item moniker is bound, the container of your objects must implement the IOleItemContainer interface.

The most common example of moniker providers are OLE applications that support linking. If your OLE application supports linking to objects smaller than a file-based documents, you need to use item monikers. For a server application that allows linking to a selection within a document, you use the item monikers to identify those objects. For a container application that allows linking to embedded objects, you use the item monikers to identify the embedded objects.

Remarks

IMoniker::BindToObject
Since the URL Moniker supports asynchronous binding, the actual return value of its BindToObject may vary depending on the object parameters established in the bind-context, however the semantics of the bind operation are identical regardless of synchronous or asynchronous usage, and are as follows:
  1. The URL Moniker pulls further information for the bind operation from the bind context. For example, the moniker can obtain pointers to the IBindStatusCallback and IEnumFORMATETC interfaces that are registered in the bind context. Note that further information can include additional bind options specified on the bind context through IBindCtx::SetBindOptions, such as the dwTickCountDeadline parameter or the grfFlags value of BIND_MAYBOTHERUSER.

  2. Next, the moniker checks the Running Object Table of the bind-context to determine if the referenced object is already running. The moniker can obtain this information with the following calls:
IBindCtx::GetRunningObjectTable(&prot)
prot->IsRunning(this)
 
prot->GetObject(this, &punk)
 
pmkNewlyRunning->IsEqual
 

See Also

CreateURLMoniker, IPersistStream - URL Moniker Implementation