Recall that the operating system interacts with the run-time support for the programming language to pass on events such as keystrokes and mouse movements. These are automatically resolved into high level events in terms of the components being manipulated by the program, such as buttons, etc.
Events are despatched sequentially by the run-time support system to the program. Thus, if the user clicks a button such as redraw in a graphics application, until the redrawing is completed the application cannot respond to other events. However, the user is clearly free to move the mouse and press some keys while the redrawing is in progress. These events are stored in an event queue and processed in turn.
One advantage of storing events in a queue is that they can be optimized. For instance, if there are three mouse movements while the redrawing is in progress, it is sufficient to record the position of the mouse at the end of the last of the three movements in the queue.
What events go in the queue? We have so far indicated that the program receives only high level, or ``semantic'', events such as ``button b was pushed''. These are synthesized by the run-time support system from the low level events that it receives from the operating system.
However, a program may also like to receive low level events such as mouse movements and key strokes. Consider a drawing application where the user can draw a line segment by using the mouse to click both end points. After selecting the first point, it would be complicated if the user could wander off and do other things before identifying the second point. In such a situation, after being notified that the first point has been selected, which is perhaps a high level event, the program can go into a loop where it explicitly ``consumes'' events in the queue until it sees the next mouse click within the drawing area. All irrelevant intervening events are discarded. Thus, by examining low level events, the program can ``grab'' control of the user and force the user to act in a predictable way.
The low level support for event management in Java is done by a portion of the AWT system. The AWT system does in fact insert both low level and high level events in the queue. The low level events are essentially those received from the operating system, but these may be combined and optimized as indicated earlier. In addition, AWT keeps track of how high level components are affected by these low level events and inserts appropriate high level events into the queue.
Low level events have listener interfaces, just like high level ones. Thus, normally, a Java program interacts with the event queue implicitly, by defining appropriate listeners for the various events of interest. When an event reaches the head of the queue, it activates all the listeners that exist for it. If there are no listeners active, the event is discarded.
In addition, a Java program can also explicitly interact with the event queue. Java has a built-in class called EventQueue. An object of this class can hold a pointer to the current system event queue. This is done as follows.
EventQueue evtq = Toolkit.getDefaultToolkit().getSystemEventQueue();
It is then possible to consume an event from the head of the event queue explicitly, as follows.
AWTEvent evt = eq.getNextEvent();
(It is also possible to ``peek'' at the event at the head of the queue without consuming it.)
We can use this explicit event queue manipulating facility to write event grabbing code such as the line drawing application discussed earlier that insists on a second point being selected after the first point has been placed.
Dually, we can also add events to the queue from within the program by writing something like
evtq.postEvent(new ActionEvent(.....));
Thus, when one button is pressed, one of the effects could be to internally generate an event corresponding to another button being pressed. For instance, a button labelled Exit might generate a frame-closing event for its enclosing frame which, when handled, will shut down the application.