IBindStatusCallback::GetBindInfoIBindStatusCallback::GetBindInfo*
*Contents  *Index  *Topic Contents
*Previous Topic: IBinding::Suspend
*Next Topic: IBindStatusCallback::GetPriority

IBindStatusCallback::GetBindInfo

HRESULT GetBindInfo(
    [out] DWORD *pgrfBINDF,
    [in, out] BINDINFO *pbindinfo
);

Obtains the bind information for the bind operation when called by an asynchronous moniker.

pgrfBINDF
Address of a value taken from the BINDF enumeration indicating whether the bind should proceed synchronously or asynchronously.
pbindinfo
Address of the BINDINFO structure, which describes how the client wants the binding to occur.

The moniker calls this method in its implementations of the IMoniker::BindToObject and IMoniker::BindToStorage methods to obtain information about the specific bind operation.

Asynchronous moniker clients should be aware that a moniker might call this method more than once during a bind operation. A proper implementation of IBindStatusCallback::GetBindInfo should prepare for this possibility. If returning data in the pbindinfo parameter, the implementation should allocate the appropriate data (szExtraInfo and/or stgmedData) at the time of each call. In this way, if the callback is never called, data is never allocated; if the callback is called more than once, it will work correctly. The first time this callback is received by the asynchronous moniker client is before the call to IMoniker::BindToStorage or IMoniker::BindToObject.

Even when the value of pgrfBINDF is BINDF_ASYNCHRONOUS, it is possible that the original call to IMoniker::BindToStorage or IMoniker::BindToObject might return synchronously rather than returning the MK_S_ASYNCHRONOUS flag. Clients of asynchronous monikers should always prepare for this possibility. Specifically, to avoid memory leaks, it is important to make sure to release the pointer returned by a call to either method.

One way to deal with this case is to call your own implementation of IBindStatusCallback::OnDataAvailable or IBindStatusCallback::OnObjectAvailable in order to use the same code path (regardless of whether you bind synchronously or asynchronously).

If the BINDF_PULLDATA value is not set in the pgrfBINDF parameter, Urlmon.dll sets the BINDF_NEEDFILE value. If BINDF_NEEDFILE is set, binding of resources that cannot be cached (such as an https resource) will fail.

Warning The size of the BINDINFO structure has changed with the release of Microsoft Internet Explorer 4.0. Developers must write code that checks the size of the BINDINFO structure that is passed into their implementation of this method before writing to members of the structure. See Handling BINDINFO Structures in Asynchronous and URL Monikers Overview for more information.

See also BINDF, BINDINFO, RegisterBindStatusCallback

Up Top of Page
© 1997 Microsoft Corporation. All rights reserved. Terms of Use.