Share via


IBindStatusCallback::GetBindInfo

A version of this page is also available for

Windows Embedded CE 6.0 R3

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 BINDF enumeration that indicate how the bind process should be handled.
  • pbindinfo
    [in, out] Address of the BINDINFO structure, 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::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 multiple times during a bind operation. A correct 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 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::BindToStorage or IMoniker::BindToObject.

Even when the value of grfBindInfoF is BINDF_ASYNCHRONOUS, it is possible that the original call to IMoniker::BindToStorage or IMoniker::BindToObject might 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::OnDataAvailable or IBindStatusCallback::OnObjectAvailable to use the same code path, regardless of whether you bind synchronously or asynchronously.

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

Note

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.

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

Reference

URL Moniker Services Interfaces