Click to return to the Networking, Protocols     
IBindStatusCallback Inter...     IBindStatusCallback::GetP...     IBindStatusCallback Inter...    
Web Workshop  |  Networking, Protocols & Data Formats

IBindStatusCallback::GetBindInfo Method


Provides information about how the bind operation should be handled when called by an asynchronous moniker.

Syntax

HRESULT GetBindInfo(
    DWORD *pgrfBINDF,
    BINDINFO *pbindinfo
);

Parameters

pgrfBINDF
[out] Address of an unsigned integer value that contains a combination of values taken from the BINDF enumeration indicating how the bind process should be handled.
pbindinfo
[in, out] Address of the BINDINFO structure, which describes how the client application wants the binding to occur.

Return Value

Returns S_OK if successful, or E_INVALIDARG if one or more parameters are invalid.

Remarks

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 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. For more information, see Handling BINDINFO Structures in the URL Monikers Overview.

Windows CE

Windows CE Use version 2.12 and later
Minimum availability Internet Explorer 4.0

See Also

RegisterBindStatusCallback



Back to topBack to top

Did you find this topic useful? Suggestions for other topics? Write us!

© 1999 Microsoft Corporation. All rights reserved. Terms of use.