Applets - Java Examples in a Nutshell - page 381

methods to process events. This means that you must create a subclass to define
custom event-handling behavior, which is exactly what you do when you write an
applet, for example. Notice, however, that not all the event types are dispatched
by handleEvent() to more specific methods. So, if you are interested in
LIST_SELECT or WINDOW_ICONIFY events, for example, you have to override han-
dleEvent() itself, rather than one of the more specific methods. If you do this,
you should usually invoke super.handleEvent() to continue dispatching events of
other types in the default way.
The handleEvent() method, and all the type-specific methods, return boolean val-
ues. If an event-handling method returns false , as they all do by default, it means
that the event was not handled, so it should be passed to the container of the cur-
rent component to see if that container is interested in processing it. If a method
returns true , on the other hand, it is a signal that the event has been handled, and
no further processing is needed.
The fact that unhandled events are passed up the containment hierarchy is impor-
tant. It means that you can override the action() method (for example) in an
applet in order to handle the ACTION_EVENT events that are generated by the but-
tons within the applet. If they were not propagated up as they are, you would
have to create a custom subclass of Button for every button you wanted to add to
an interface.
In the Java 1.0 model, there is no de facto way to know what types of events are
generated by what GUI components, nor to know what fields of the Event object
are filled in for what types of events. You simply have to look up this information
in the documentation of individual AWT components.
Many event types use the modifiers field of the Event object to report which key-
board modifier keys were depressed when the event occurred. This field contains
a bitmask of the SHIFT_MASK , CTRL_MASK , META_MASK , and ALT_MASK constants
defined by the Event class. The shiftDown() , controlDown() , and metaDown()
methods can test for the various modifiers. When a mouse event occurs, the Event
class does not have a special field to indicate which mouse button was pressed.
Instead, this information is provided by reusing the keyboard modifier constants.
This allows such systems as the Macintosh that use a one-button mouse to simu-
late other mouse buttons by using keyboard modifiers. If the left mouse button is
in use, no keyboard modifiers are reported. If the right button is used, the
META_MASK bit is set in the modifiers field. And if the middle button is down, the
ALT_MASK bit is set.
When a keyboard event occurs, you should check the id field of the Event object
to determine what kind of key was pressed. If the event type is KEY_PRESS or
KEY_RELEASE , the keyboard key has an ASCII or Unicode representation and the
key field of the event object contains the encoding of the key. On the other hand,
if id is KEY_ACTION or KEY_ACTION_RELEASE , the key is a function key of some sort,
and the key field contains one of the keyboard constants defined by the Event
class, such as Event.F1 or Event.LEFT .
Keep this quick introduction to the Java 1.0 event model in mind as you read over
Example 15-3. This applet allows the user to produce simple drawings by scrib-
bling with the mouse. It also allows the user to erase those drawings by clicking