IMoniker::BindToObject
Uses the moniker
to bind to the object it identifies. The binding process involves finding the
object, putting it into the running state if necessary, and supplying the
caller with a pointer to a specified interface on the identified object.
HRESULT BindToObject(
IBindCtx *pbc, |
//Pointer to bind context object to be used |
IMoniker *pmkToLeft, |
//Pointer to moniker that precedes this one in the
composite |
REFIID riidResult, |
//IID of interface pointer requested |
void **ppvResult |
//Indirect pointer to the specified interface on the
object |
); |
|
Parameters
pbc
[in] Pointer
to the IBindCtx
pmkToLeft
[in] If the
moniker is part of a composite moniker, pointer to the moniker to the left of
this moniker. This parameter is primarily used by moniker implementers to
enable cooperation between the various components of a composite moniker.
Moniker clients should pass NULL.
riidResult
[in] IID of
the interface the client wishes to use to communicate with the object that the
moniker identifies.
ppvResult
[out] When
successful, indirect pointer to the interface specified in riidResult on
the object the moniker identifies. In this case, the implementation must call IUnknown::AddRef
Return Values
The method
supports the standard return values E_UNEXPECTED and E_OUTOFMEMORY, as well as
the following:
S_OK
The binding
operation was successful.
MK_E_NOOBJECT
The object identified
by this moniker, or some object identified by the composite moniker of which
this moniker is a part, could not be found.
MK_E_EXCEEDEDDEADLINE
The binding
operation could not be completed within the time limit specified by the bind
context s BIND_OPTS
MK_E_CONNECTMANUALLY
The binding
operation requires assistance from the end user. The most common reasons for
returning this value are that a password is needed or that a floppy needs to be
mounted. When this value is returned, retrieve the moniker that caused the
error with a call to IBindCtx::GetObjectParamXAEQT6 with the key ConnectManually . You can
then call IMoniker::GetDisplayName to get the display name, display a
dialog box that communicates the desired information, such as instructions to
mount a floppy or a request for a password, and then retry the binding
operation.
MK_E_INTERMEDIATEINTERFACENOTSUPPORTED
An
intermediate object was found but it did not support an interface required to
complete the binding operation. For example, an item moniker returns this value
if its container does not support the IOleItemContainer interface.
STG_E_ACCESSDENIED
Unable to
access the storage object.
IOleItemContainer::GetObject errors
If the
moniker used to bind to an object contains an item moniker, errors associated
with this method can be returned.
Remarks
IMoniker::BindToObject implements the primary function of a moniker, which
is to locate the object identified by the moniker and return a pointer to one
of its interfaces.
Notes to Callers
If you are
using a moniker as a persistent connection between two objects, you activate
the connection by calling IMoniker::BindToObject.
You typically
call IMoniker::BindToObject during the following process:
1. Create a bind context object with a call to
the CreateBindCtx
function.
2. Call IMoniker::BindToObject using the
moniker, retrieving a pointer to a desired interface on the identified object.
3. Release the bind context.
4. Through the acquired interface pointer,
perform the desired operations on the object.
5. When finished with the object, release the
object s interface pointer.
The following
code fragment illustrates these steps:
// pMnk is an IMoniker * that points to a previously
acquired moniker
// ICellRange is a custom interface designed for an
object that is a
//
range of spreadsheet cells
ICellRange *pCellRange;
IBindCtx *pbc;
CreateBindCtx( 0, &pbc );
pMnk->BindToObject( pbc, NULL, IID_ICellRange,
&pCellRange );
pbc->Release();
// pCellRange now points to the object; safe to use
pCellRange
pCellRange->Release();
You can also
use the BindMoniker
OLE
containers that support links to objects use monikers to locate and get access
to the linked object, but typically do not call IMoniker::BindToObject
directly. Instead, when a user activates a link in a container, the link
container usually calls IOleObject::DoVerb, using the link handler s
implementation, which calls IMoniker::BindToObject on the moniker stored
in the linked object (if it cannot handle the verb).
Notes to Implementers
What your
implementation does depends on whether you expect your moniker to have a
prefix, that is, whether you expect the pmkToLeft parameter to be NULL
or not. For example, an item moniker, which identifies an object within a
container, expects that pmkToLeft identifies the container. An item
moniker consequently uses pmkToLeft to request services from that
container. If you expect your moniker to have a prefix, you should use the pmkToLeft
parameter (for instance, calling IMoniker::BindToObject on it) to
request services from the object it identifies.
If you expect
your moniker to have no prefix, your IMoniker::BindToObject
implementation should first check the Running Object Table (ROT) to see if the
object is already running. To acquire a pointer to the ROT, your implementation
should call IBindCtx::GetRunningObjectTable
When your IMoniker::BindToObject
implementation binds to some object, it should use the pbc parameter to
call IBindCtx::RegisterObjectBound
If the bind
context s BIND_OPTS
See Also