Next: Eventspaces and Threads Up: Overview Previous: Known Problems

Eventspaces

An eventspace is a context for processing graphical interface events. Each eventspace maintains its own queue of events, and events for a single eventspace are handled sequentially; i.e., after each event is read from the queue, the procedure that is invoked to handle the event must return before another event is dequeued. However, events from different eventspaces are dequeued and handled independently. Handler procedures from different eventspaces can run simultaneously (using separate threads).

When a top-level frame or dialog is created, it is associated with a particular eventspace (the ``current eventspace'' as described in Creating and Setting the Eventspace). All events for the frame or dialog and its decendents are queued in its eventspace; therefore, events for a single frame or dialog are always handled sequentially.

If two frames are in the same eventspace, all events from both frames are handled sequentially. For example, a mouse-click event in one of the frames must be fully handled (i.e., the mouse click callback procedure must return a value) before any event will be processed for the other frame. In contrast, if two frames are in different eventspaces, events are handled in parallel; two event handlers (one from each frame) can run simultaneously.

Timer objects are also associated with a eventspace. Timer callbacks (i.e., the notify method of a wx:timer% instance) are queued as ``time-out'' events that are handled sequentially with other events from the same eventspace.

A modal dialog sets a mode only within its own eventspace. For example, if a modal message dialog is opened in one eventspace, then all other frames and dialogs in the same eventspace are disabled. However, frames and dialogs in different eventspaces are unaffected by the modal dialog.

A programmer can control the timing of event dispatches in an eventspace by setting the event dispatch handler via the wx:event-dispatch-handler parameter.