NAME

XtAppNextEvent, XtAppPending, XtAppPeekEvent, XtAppProcessEvent, XtDispatchEvent, XtAppMainLoop - query and process events and input

SYNTAX

void XtAppNextEvent(XtAppContext _a_p_p___c_o_n_t_e_x_t, XEvent *_e_v_e_n_t___r_e_t_u_r_n); Boolean XtAppPeekEvent(XtAppContext _a_p_p___c_o_n_t_e_x_t, XEvent *_e_v_e_n_t___r_e_t_u_r_n); XtInputMask XtAppPending(XtAppContext _a_p_p___c_o_n_t_e_x_t); void XtAppProcessEvent(XtAppContext _a_p_p___c_o_n_t_e_x_t, XtInputMask _m_a_s_k); Boolean XtDispatchEvent(XEvent *_e_v_e_n_t); void XtAppMainLoop(XtAppContext _a_p_p___c_o_n_t_e_x_t);

ARGUMENTS

_a_p_p___c_o_n_t_e_x_t Specifies the application context that identifies the application .
_e_v_e_n_t Specifies a pointer to the event structure that is to be dispatched
to the appropriate event handler.
_e_v_e_n_t___r_e_t_u_r_n Returns the event information to the specified event structure.
_m_a_s_k Specifies what types of events to process.
The mask is the bitwise inclusive OR of any combination of _X_t_I_M_X_E_v_e_n_t, _X_t_I_M_T_i_m_e_r, _X_t_I_M_A_l_t_e_r_n_a_t_e_I_n_p_u_t, and _X_t_I_M_S_i_g_n_a_l. As a convenience, the X Toolkit defines the symbolic name _X_t_I_M_A_l_l to be the bitwise inclusive OR of all event types.

DESCRIPTION

If the X event queue is empty, _X_t_A_p_p_N_e_x_t_E_v_e_n_t flushes the X output buffers of each Display in the application context and waits for an event while looking at the other input sources, timeout timeout values, and signal handlers 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, _X_t_A_p_p_P_e_e_k_E_v_e_n_t fills in the event and returns a nonzero value. If no X input is on the queue, _X_t_A_p_p_P_e_e_k_E_v_e_n_t flushes the output buffer and blocks until input is available (possibly calling some timeout callbacks in the process). If the input is an event, _X_t_A_p_p_P_e_e_k_E_v_e_n_t fills in the event and returns a nonzero value. Otherwise, the input is for an alternate input source, and _X_t_A_p_p_P_e_e_k_E_v_e_n_t returns zero.

The _X_t_A_p_p_P_e_n_d_i_n_g 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 _X_t_I_M_X_E_v_e_n_t, _X_t_I_M_T_i_m_e_r, _X_t_I_M_A_l_t_e_r_n_a_t_e_I_n_p_u_t, and _X_t_I_M_S_i_g_n_a_l (see _X_t_A_p_p_P_r_o_c_e_s_s_E_v_e_n_t). If there are no events pending, _X_t_A_p_p_P_e_n_d_i_n_g flushes the output buffer and returns zero.

The _X_t_A_p_p_P_r_o_c_e_s_s_E_v_e_n_t function processes one timer, alternate input, signal source, or X event. If there is nothing of the appropriate type to process, _X_t_A_p_p_P_r_o_c_e_s_s_E_v_e_n_t 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 _X_t_A_p_p_M_a_i_n_L_o_o_p). _X_t_A_p_p_P_r_o_c_e_s_s_E_v_e_n_t processes timer events by calling any appropriate timer callbacks, alternate input by calling any appropriate alternate input callbacks, signal source by calling any appropriate signal callbacks, and X events by calling _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t.

When an X event is received, it is passed to _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t, 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 _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t function sends those events to the event handler functions that have been previously registered with the dispatch routine. _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t returns _T_r_u_e if it dispatched the event to some handler and _F_a_l_s_e if it found no handler to dispatch the event to. The most common use of _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t is to dispatch events acquired with the _X_t_A_p_p_N_e_x_t_E_v_e_n_t procedure. However, it also can be used to dispatch user-constructed events. _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t also is responsible for implementing the grab semantics for _X_t_A_d_d_G_r_a_b.

The _X_t_A_p_p_M_a_i_n_L_o_o_p function first reads the next incoming X event by calling _X_t_A_p_p_N_e_x_t_E_v_e_n_t and then it dispatches the event to the appropriate registered procedure by calling _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t. This constitutes the main loop of X Toolkit applications, and, as such, it does not return unless _X_t_A_p_p_S_e_t_E_x_i_t_F_l_a_g is called. Applications are expected to exit in response to some user action. There is nothing special about _X_t_A_p_p_M_a_i_n_L_o_o_p; it is simply an loop that calls _X_t_A_p_p_N_e_x_t_E_v_e_n_t and then _X_t_D_i_s_p_a_t_c_h_E_v_e_n_t, until _X_t_A_p_p_G_e_t_E_x_i_t_F_l_a_g() returns true.

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_t_A_p_p_N_e_x_t_E_v_e_n_t.

SEE ALSO


_X _T_o_o_l_k_i_t _I_n_t_r_i_n_s_i_c_s _- _C _L_a_n_g_u_a_g_e _I_n_t_e_r_f_a_c_e
_X_l_i_b _- _C _L_a_n_g_u_a_g_e _X _I_n_t_e_r_f_a_c_e