IBindCtx  2O_49TK

The IBindCtx interface provides access to a bind context, which is an object that stores information about a particular moniker binding operation. You pass a bind context as a parameter when calling many methods of IMoniker18XK102 and in certain functions related to monikers.

A bind context includes the following information:

    A BIND_OPTS3_HO_Y. structure containing a set of parameters that do not change during the binding operation. When a composite moniker is bound, each component uses the same bind context, so it acts as a mechanism for passing the same parameters to each component of a composite moniker.

    A set of pointers to objects that the binding operation has activated. The bind context holds pointers to these bound objects, keeping them loaded and thus eliminating redundant activations if the objects are needed again during subsequent binding operations.

    A pointer to the Running Object Table on the machine of the process that started the bind operation. Moniker implementations that need to access the Running Object Table should use the IBindCtx::GetRunningObjectTable5J01OF method rather than using the GetRunningObjectTable function. This allows future enhancements to the system s IBindCtx implementation to modify binding behavior.

    A table of interface pointers, each associated with a string key. This capability enables moniker implementations to store interface pointers under a well-known string so that they can later be retrieved from the bind context. For example, OLE defines several string keys (e.g.,  ExceededDeadline ,  ConnectManually ) that can be used to store a pointer to the object that caused an error during a binding operation.

When to Implement

You do not need to implement this interface. The system provides an IBindCtx implementation, accessible though a call to the CreateBindCtx6NHJ.W6 function, that is suitable for all situations.

When to Use

Anyone writing a new moniker class by implementing the IMoniker18XK102 interface must call IBindCtx methods in the implementation of several IMoniker methods. Moniker providers (servers that hand out monikers to identify their objects) may also need to call IBindCtx methods from their implementations of the IOleItemContainer or IParseDisplayNameQD_Z28 interfaces.

Moniker clients (objects that use monikers to acquire interface pointers to other objects) typically don t call many IBindCtx methods. Instead, they simply pass a bind context as a parameter in a call to an IMoniker method. To acquire an interface pointer and activate the indicated object (called binding to an object), moniker clients typically do the following:

  1.  Call the CreateBindCtx6NHJ.W6 function to create a bind context and get a pointer to the IBindCtx interface on the bind context object..

  2.  If desired (although this is rarely necessary), the moniker client can call IBindCtx::SetBindOptions.L_W2Z to specify the bind options.

  3.  Pass the bind context as a parameter to the desired IMoniker18XK102 method (usually IMoniker::BindToObject486P_PV).

  4.  Call IUnknown::ReleaseDUW01A on the bind context to release it.

Although applications that act as link containers (container applications that allow their documents to contain linked objects) are moniker clients, they rarely call IMoniker methods directly. Generally, they manipulate linked objects through the system implementation (in the default handler) of the IOleLink interface. This implementation calls the appropriate IMoniker methods as needed, and, in doing so, passes pointers to IBindCtx interfaces on the proper bind context objects.

Methods in Vtable Order

See Also

CreateBindCtx6NHJ.W6, IMoniker18XK102, IOleItemContainer1MMKGIR, IParseDisplayNameQD_Z28