Called if a Windows message or Macintosh event appears in the queue while OLE
is waiting to reply to a remote call.
| HTASK threadIDCallee,
||//Called applications task handle
| DWORD dwTickCount,
||//Elapsed tick count
| DWORD dwPendingType
[in] Specifies the task handle of the called application that has not yet
[in] Specifies the number of ticks since the call was made. It is calculated
from the Windows GetTickCount
function, or the Macintosh function, TickCount
[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):
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
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.
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
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.
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
parameter. This ensures that:
- if calls are completed in a reasonable amount of time, type ahead will be
- 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.
Returning PENDINGMSG_WAITNOPROCESS can cause the message queue to fill.
GetTickCount in Win32
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages