Event types
As mentioned above, the Event class is a model of a user interface event. Events naturally fall into categories based on the type of the event (the event type is indicated by the id
data member). Table 2 lists all of the events defined by the AWT, sorted by category.
Window events | |
Window events are generated in response to changes in the state of a window, frame, or dialog. | |
Event | ID |
WINDOW_DESTROY | 201 |
WINDOW_EXPOSE | 202 |
WINDOW_ICONIFY | 203 |
WINDOW_DEICONIFY | 204 |
WINDOW_MOVED | 205 |
Keyboard events | |
Keyboard events are generated in response to keys pressed and released while a component has input focus. | |
Event | ID |
KEY_PRESS | 401 |
KEY_RELEASE | 402 |
KEY_ACTION | 403 |
KEY_ACTION_RELEASE | 404 |
Mouse events | |
Mouse events are generated in response to mouse actions occurring within the boundary of a component. | |
Event | ID |
MOUSE_DOWN | 501 |
MOUSE_UP | 502 |
MOUSE_MOVE | 503 |
MOUSE_ENTER | 504 |
MOUSE_EXIT | 505 |
MOUSE_DRAG | 506 |
Scroll events | |
Scroll events are generated in response to manipulation of scrollbars. | |
Event | ID |
SCROLL_LINE_UP | 601 |
SCROLL_LINE_DOWN | 602 |
SCROLL_PAGE_UP | 603 |
SCROLL_PAGE_DOWN | 604 |
SCROLL_ABSOLUTE | 605 |
List events | |
List events are generated in response to selections made to a list. | |
Event | ID |
LIST_SELECT | 701 |
LIST_DESELECT | 702 |
Miscellaneous events | |
Miscellaneous events are generated in response to a variety of actions. | |
Event | ID |
ACTION_EVENT | 1001 |
LOAD_FILE | 1002 |
SAVE_FILE | 1003 |
GOT_FOCUS | 1004 |
LOST_FOCUS | 1005 |
It can be instructive to see event generation in action. The button in Figure 1, when pressed, creates an event browser that displays event information about the events the browser receives. The source code for the event browser is available here.
Figure 1: Event generation in action
Event dispatch and propagation
Consider the applet in Figure 2. It consists of two instances of the Button class, embedded within an instance of the Panel class. This instance of the Panel class is itself embedded within another instance of the Panel class. The latter instance of the Panel class sits below an instance of class TextArea, and both instances are embedded within an instance of the Applet class. Figure 3 presents the elements that make up this applet laid out as a tree, with the TextArea and Button instances as the leaves, and an Applet instance as the root. (For more information about the hierarchical layout of components in a user interface, read last month's introduction to the AWT.)
Figure 2: Classes embedded within classes
Figure 3: Applet elements tree (hierarchy)
When a user interacts with the applet in Figure 2, the Java run-time system creates an instance of class Event and fills its data members with information describing the action. The Java run-time system then allows the applet to handle the event. It begins with the component that initially received the event (for instance, the button that was clicked) and moves up the component tree, component by component, until it reaches the container at the top of the tree. Along the way, each component has the opportunity to ignore the event or to react to it in one (or more) of the following ways:
- Modify the data members of the Event instance
- Take action and perform some computation based on the information contained in the event
- Indicate to the Java run-time system that the event should propagate no further up the tree
The Java run-time system passes event information to a component via the component's handleEvent()
method. All valid handleEvent()
methods must be of the form
public boolean handleEvent(Event e)
An event handler requires a single piece of information: a reference to the instance of the Event class containing information about the event that just occurred.
The value returned from the handleEvent()
method is important. It indicates to the Java run-time system whether or not the event has been completely handled within the event handler. A true value indicates that the event has been handled and propagation should stop. A false value indicates that the event has been ignored, could not be handled, or has been handled incompletely and should continue up the tree.
Consider the following description of an imaginary user's interaction with the applet in Figure 2. The user clicks on the button labeled "One." The Java language run-time system gathers information about the event (the number of clicks, the location of the click, the time the click occurred, and the component that received the click) and packages that information in an instance of the Event class. The Java run-time system then begins at the component that was clicked (in this case, the Button labeled "One") and, via a call to the component's handleEvent()
method, offers the component a chance to react to the event. If the component does not handle the event or handles the event incompletely (indicated by a return value of false), the Java run-time system offers the Event instance to the next higher component in the tree -- in this case an instance of the Panel class. The Java run-time system continues in this manner until the event is handled or the run-time system runs out of components to try. Figure 4 illustrates the path of this event as the applet attempts to handle it.
Figure 4: The path of an event
Each component making up the applet in Figure 2 adds a line to the TextArea object that indicates it received an event. It then allows the event to propagate to the next component in the tree. Listing 1 contains the code for a typical handleEvent()
method. The complete source code for this applet is available here.
public boolean handleEvent(Event evt)
{
if (evt.id == Event.ACTION_EVENT)
{
ta.appendText("Panel " + str + " saw action.../n");
}
else if (evt.id == Event.MOUSE_DOWN)
{
ta.appendText("Panel " + str + " saw mouse down.../n");
}
return super.handleEvent(evt);
}
Listing 1: A typical handleEvent()
method
Event helper methods
The handleEvent()
method is one place a programmer can put application code for handling events. Occasionally, however, a component will only be interested in events of a certain type (for example, mouse events). In these cases, the programmer can place the code in a helper method, rather than placing it in the handleEvent()
method.
Here is a list of the helper methods available to programmers. There are no helper methods for certain types of events.
action(Event evt, Object what)
gotFocus(Event evt, Object what)
lostFocus(Event evt, Object what)
mouseEnter(Event evt, int x, int y)
mouseExit(Event evt, int x, int y)
mouseMove(Event evt, int x, int y)
mouseUp(Event evt, int x, int y)
mouseDown(Event evt, int x, int y)
mouseDrag(Event evt, int x, int y)
keyDown(Event evt, int key)
keyUp(Event evt, int key)
false to indicate that the helper method did not handle the event.
The implementation of the handleEvent()
method provided by class Component invokes each helper method. For this reason, it is important that the redefined implementations of the handleEvent()
method in derived classes always end with the statement
return super.handleEvent(e);
The code in Listing 2 illustrates this rule.
public boolean handleEvent(Event e)
{
if (e.target instanceof MyButton)
{
// do something...
return true;
}
return super.handleEvent(e);
}