XtAppNextEvent(3Xt) MIT X11R4 XtAppNextEvent(3Xt)
XtAppNextEvent, XtAppPending, XtAppPeekEvent, XtAppProcessEvent, XtDispatchEvent, XtAppMainLoop - query and process events and input
void XtAppNextEvent(app_context, event_return)
Boolean XtAppPeekEvent(app_context, event_return)
void XtAppProcessEvent(app_context, mask)
Specifies the application context that identifies the application .
event Specifies a pointer to the event structure that is to be dispatched to the appropriate event handler.
Returns the event information to the specified event structure.
mask Specifies what types of events to process. The mask is the bitwise inclusive OR of any combination of and As a convenience, the
X Toolkit defines the symbolic name to be the bitwise inclusive OR of all event types.
If no input is on the X input queue, flushes the X output buffer and waits for an event while looking at the other input sources and time-
out values and calling any callback procedures triggered by them. This wait time can be used for background processing (see Section 7.8).
If there is an event in the queue, fills in the event and returns a nonzero value. If no X input is on the queue, flushes the output buf-
fer and blocks until input is available (possibly calling some timeout callbacks in the process). If the input is an event, fills in the
event and returns a nonzero value. Otherwise, the input is for an alternate input source, and returns zero.
The function returns a nonzero value if there are events pending from the X server, timer pending, or other input sources pending. The
value returned is a bit mask that is the OR of and (see If there are no events pending, flushes the output buffer and returns zero.
The function processes one timer, alternate input, or X event. If there is nothing of the appropriate type to process, blocks until there
is. If there is more than one type of thing available to process, it is undefined which will get processed. Usually, this procedure is
not called by client applications (see processes timer events by calling any appropriate timer callbacks, alternate input by calling any
appropriate alternate input callbacks, and X events by calling
When an X event is received, it is passed to which calls the appropriate event handlers and passes them the widget, the event, and client-
specific data registered with each procedure. If there are no handlers for that event registered, the event is ignored and the dispatcher
simply returns. The order in which the handlers are called is undefined.
The function sends those events to the event handler functions that have been previously registered with the dispatch routine. returns if
it dispatched the event to some handler and if it found no handler to dispatch the event to. The most common use of is to dispatch events
acquired with the procedure. However, it also can be used to dispatch user-constructed events. also is responsible for implementing the
grab semantics for
The function first reads the next incoming X event by calling and then it dispatches the event to the appropriate registered procedure by
calling This constitutes the main loop of X Toolkit applications, and, as such, it does not return. Applications are expected to exit in
response to some user action. There is nothing special about it is simply an infinite loop that calls and then
Applications can provide their own version of this loop, which tests some global termination flag or tests that the number of top-level
widgets is larger than zero before circling back to the call to
X Window System Toolkit: The Complete Programmer's Guide and Specification, Paul J. Asente and Ralph Swick
X Window System: The Complete Reference, Second Edition, Robert W. Scheifler and James Gettys