IXPLogon::FlushQueues

The IXPLogon::FlushQueues method requests that the transport provider immediately deliver all pending inbound or outbound messages.

Quick Info

See IXPLogon : IUnknown.

HRESULT FlushQueues(
  ULONG ulUIParam,           
  ULONG cbTargetTransport,   
  LPENTRYID lpTargetTransport,   
  ULONG ulFlags              
);
 

Parameters

ulUIParam

[in] Handle of the parent window for any dialog boxes or windows this method displays.

cbTargetTransport

Reserved; must be zero.

lpTargetTransport

Reserved; must be NULL.

ulFlags

[in] Bitmask of flags that controls how message queue flushing is done. The following flags can be set:

FLUSH_DOWNLOAD

The inbound message queue or queues should be flushed.

FLUSH_FORCE

The transport provider should process this request if possible, even if doing so is time-consuming.

FLUSH_NO_UI

The transport provider should not display a user interface.

FLUSH_UPLOAD

The outbound message queue or queues should be flushed.

Return Values

S_OK

The call succeeded and has returned the expected value or values.

Remarks

The MAPI spooler calls the IXPLogon::FlushQueues method to advise the transport provider that the MAPI spooler is about to begin processing messages. The transport provider should call the IMAPISupport::ModifyStatusRow method to set an appropriate bit for its state in the PR_STATUS_CODE property of its status row. After updating its status row, the transport provider should return S_OK for the FlushQueues call. The MAPI spooler then starts sending messages, with the operation being synchronous to the MAPI spooler.

To support its implementation of the IMAPIStatus::FlushQueues method, the MAPI spooler calls IXPLogon::FlushQueues for all logon objects for active transport providers running in a profile session. When a transport provider's FlushQueues method is called as a result of a client application calling IMAPIStatus::FlushQueues, the message processing occurs asynchronously to the client.

See Also

IMAPIStatus::FlushQueues