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.
A version of this page is also available for
4/8/2010

This method provides information about how the bind operation should be handled when it is called by an asynchronous moniker.

Syntax 

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

Parameters

grfBINDF

[out] Address of an unsigned integer value that contains a combination of values taken from the BINDFenumeration that indicate how the bind process should be handled.

pbindinfo

[in, out] Address of the BINDINFOstructure, which describes the client application's requirements for binding.

Return Value

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

Remarks

The moniker calls this method in its implementations of the IMoniker::BindToObjectand IMoniker::BindToStoragemethods to obtain information about the specific bind operation.

Asynchronous moniker clients should be aware that a moniker might call this method multiple times during a bind operation. A correct implementation of IBindStatusCallback::GetBindInfoshould prepare for this possibility. If returning data in the pbindinfoparameter, the implementation should allocate the appropriate data ( szExtraInfoand stgmedData) at the time of each call. In this manner, if the callback is never called, data is never allocated; if the callback is called multiple times, it will work correctly. The first time this callback is received by the asynchronous moniker client is before the call to IMoniker::BindToStorageor IMoniker::BindToObject.

Even when the value of grfBindInfoFis BINDF_ASYNCHRONOUS, it is possible that the original call to IMoniker::BindToStorageor IMoniker::BindToObjectmight return synchronously instead of returning the MK_S_ASYNCHRONOUS flag. Clients of asynchronous monikers should always prepare for this possibility. Specifically, to avoid memory leaks, you must make sure that you 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::OnDataAvailableor IBindStatusCallback::OnObjectAvailableto use the same code path, regardless of whether you bind synchronously or asynchronously.

If the BINDF_PULLDATA value is not set in the grfBindInfoFparameter, 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.

Note:
The size of the BINDINFOstructure changed with the release of Microsoft Internet Explorer 4.0. Developers must write code that checks the size of the BINDINFOstructure that is passed into their implementation of this method before writing to members of the structure.

Requirements

Header urlmon.h, urlmon.idl
Library urlmon.lib
Windows Embedded CE Windows CE .NET 4.0 and later
Windows Mobile Windows Mobile Version 5.0 and later

See Also