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 IMoniker
and in certain API functions related to monikers.
A bind context includes the following information:
When to Implement
- A BIND_OPTS 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; a bind context is thus 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::GetRunningObjectTable method rather than using the GetRunningObjectTable API 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.
You do not need to implement this interface. The system provides an IBindCtx
implementation, accessible using the CreateBindCtx
API function, that is suitable for all situations.
When to Use
The primary users of IBindCtx
are those who write their own implementation of the IMoniker
interface; they must call IBindCtx
methods from the implementation of several IMoniker
methods. Another category of IBindCtx
users are moniker providers (that is, those who hand out monikers that
identify their objects). They may need to call IBindCtx
methods from their implementations of the IOleItemContainer
Moniker clients (that is, those who use monikers to acquire interface pointers
to objects) typically don't call many IBindCtx
methods; they simply pass a bind context as a parameter to the IMoniker
method they're using. Moniker clients typically perform the following steps:
- Call the CreateBindCtx API function to create a bind context.
- Optionally, call the IBindCtx::SetBindOptions method in order to specify the bind options. Moniker clients rarely perform
- Pass the bind context as a parameter to the desired IMoniker method (most commonly IMoniker::BindToObject).
- Call IUnknown::Release on the bind context to release it.
The most common example of moniker clients are applications that act as link
containers, that is, container applications that allow their documents to
contain linked objects. However, link containers are a special case in that they
rarely call IMoniker
methods directly. Generally, they manipulate linked objects through the IOleLink
interface; the system-supplied linked object implements this interface and
calls the appropriate IMoniker
methods as needed. Consequently, the linked object is the one that passes
bind contexts to the IMoniker
Methods in Vtable Order
||Returns pointers to supported interfaces.
||Increments the reference count.
||Decrements the reference count.
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages