IMessageFilter::MessagePending

Called if a Windows message or Macintosh event appears in the queue while OLE is waiting to reply to a remote call.

DWORD Create(

HTASK threadIDCallee,	//Called applications task handle
DWORD dwTickCount,	//Elapsed tick count
DWORD dwPendingType	//Call type
);

Parameters

threadIDCallee

[in] Specifies the task handle of the called application that has not yet responded.

dwTickCount

[in] Specifies the number of ticks since the call was made. It is calculated from the Windows GetTickCount function, or the Macintosh function, TickCount.

dwPendingType

[in] Indicates the type of call made during which a message or event was received. Valid values are from the enumeration PENDINGTYPE (where PENDINGTYPE_TOPLEVEL means the outgoing call was not nested within a call from another application and PENDINTGYPE_NESTED means the outgoing call was nested within a call from another application):

Return Values

PENDINGMSG_CANCELCALL

Cancel the outgoing call. This should be returned only under extreme conditions. Canceling a call that has not replied or been rejected can create orphan transactions and lose resources. OLE fails the original call and return RPC_E_CALL_CANCELLED.

PENDINGMSG_WAITNOPROCESS

Continue waiting for the reply and do not dispatch the message unless it is a task-switching or window-activation message. A subsequent message will trigger another call to IMessageFilter::MessagePending. Leaving messages or events in the queue enables them to be processed normally, if the outgoing call is completed.

PENDINGMSG_WAITDEFPROCESS

Because of the increased resources available in 32-bit systems, you are unlikely to get this return value. It now indicates the same state as PENDINGMSG_WAITNOPROCESS.

Keyboard and mouse messages are no longer dispatched, as was done with PENDINGMSG_WAITDEFPROCESS. However there are some cases where mouse and keyboard messages could cause the system to deadlock, and in these cases, mouse and keyboard messages are discarded. WM_PAINT messages are dispatched. Task-switching and activation messages are handled as before.

Comments

IMessageFilter::MessagePending is called by OLE after an application has made an OLE method call and, for example, while waiting for the reply, the user selects a menu command or double-clicks an object. Before OLE makes the IMessageFilter::MessagePending call, it calculates the elapsed time since the original OLE method call was made. OLE delivers the elapsed time in the dwTickCount parameter. In the meantime, OLE does not remove the message from the queue.

Windows messages or Macintosh events that appear in the caller's queue should remain in the queue until sufficient time has passed to ensure that the messages are probably not the result of typing ahead, but are, instead, an attempt to get attention. A two- or three-second delay is recommended. If that amount of time has passed and the call has not been completed, the messages should be flushed from the queue, and a dialog box should be displayed offering the user the choice of retrying (continue waiting) or switching to the task identified by the threadIDCallee parameter. This ensures that:

• if calls are completed in a reasonable amount of time, type ahead will be treated correctly.

• if the callee does not respond, type ahead is not misinterpreted and the user is able to act to solve the problem. For example, OLE 1 servers can queue up requests without responding when they are in modal dialogs.

Handling input while waiting for an outgoing call to finish can introduce complications. The application should determine whether to process the message without interrupting the call, continue waiting, or cancel the operation.

When there is no response to the original OLE call, the application can cancel the call and restore the OLE object to a consistent state by calling IStorage::Revert on its storage. The object can be released when the container can shut down. However, canceling a call can create orphaned operations and resource leaks. Canceling should be used only as a last resort. It is strongly recommended that applications not allow such calls to be canceled.

Caution Returning PENDINGMSG_WAITNOPROCESS can cause the message queue to fill.

See Also

IStorage::Revert

GetTickCount in Win32

Software for developers

Delphi Components
.Net Components
Software for Android Developers

More information resources

MegaDetailed.Net
Unix Manual Pages
Delphi Examples

Databases for Amazon shops developers

Amazon Categories Database
Browse Nodes Database