Important: |
---|
This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
This method binds to the object named by the moniker.
HRESULT BindToObject( IBindCtx * pbc , IMoniker * pmkToLeft , REFIID riidResult , void ** ppvResult );
Parameters
Return Values
The method supports the standard return values E_UNEXPECTED and E_OUTOFMEMORY, as well as the values described in the following table.
Remarks
IMoniker::BindToObjectimplements 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::BindToObjectduring the following process:
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 BindMonikerfunction when you only intend one binding operation and don't need to retain the bind context object. This helper function encapsulates the creation of the bind context, calling IMoniker::BindToObject, and releasing the bind context.
COM containers that support links to objects use monikers to locate and get access to the linked object, but typically do not call IMoniker::BindToObjectdirectly. 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::BindToObjecton 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 pmkToLeftparameter to be NULL or not. For example, an item moniker, which identifies an object within a container, expects that pmkToLeftidentifies the container. An item moniker consequently uses pmkToLeftto request services from that container. If you expect your moniker to have a prefix, you should use the pmkToLeftparameter (for instance, calling IMoniker::BindToObjecton it) to request services from the object it identifies.
If you expect your moniker to have no prefix, your IMoniker::BindToObjectimplementation 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::GetRunningObjectTableon the pbcparameter. You can then call the IRunningObjectTable::GetObjectmethod to see if the current moniker has been registered in the ROT. If so, you can immediately call IUnknown::QueryInterfaceto get a pointer to the interface requested by the caller.
Requirements
Runs On | Versions | Defined in | Include | Link to |
---|---|---|---|---|
Windows CE OS | 2.0 and later | Oaidl.h |
Note This API is part of the complete Windows CE OS package as provided by Microsoft. The functionality of a particular platform is determined by the original equipment manufacturer (OEM) and some devices may not support this API.
See Also
BindMoniker, CreateBindCtx, IMoniker::BindToObject, IMoniker::GetDisplayName, IOleObject::DoVerb, IUnknown::AddRef, IUnknown::Release, BIND_OPTS