Java Examples In A Nutshell (3rd Edition) [Electronic resources] نسخه متنی

16.5 Applets and the Java 1.0 Event Model

The AWT event model changed dramatically
between Java 1.0 and 1.1. Chapter 11 described the
Java 1.1 event-handling model exclusively, since the Java 1.0 event
model is now deprecated. However, because there is still a
(dwindling) installed base of web browsers that support only the Java
1.0 event model, applets are sometimes still written using this
model. This section briefly describes Java 1.0 event handling and
includes an example applet that uses the model.^[1]

^[1] Note
that this section and its example are excerpted from Java
Foundation Classes in a Nutshell.

In Java 1.0, all events are represented
by the java.awt.Event class. This class has a
number of instance fields that describe the event. One of these
fields, id, specifies the type of the event.
Event defines a number of constants that are the
possible values for the id field. The
target field specifies the object (typically a
Component) that generated the event, or on which
the event occurred (i.e., the source of the event). The other fields
may or may not be used, depending on the type of the event. For
example, the x and y fields are
defined when id is
BUTTON_EVENT, but not when it is
ACTION_EVENT. The arg field can
provide additional type-dependent data.

Java 1.0
events are dispatched first to the handleEvent( )
method of the Component on which they occurred.
The default implementation of this method checks the
id field of the Event object
and dispatches the most commonly used types of events to various
type-specific methods, listed in Table 16-1.

The methods listed in Table 16-1 are defined by the
Component class. One of the primary
characteristics of the Java 1.0 event model is that you must override
these 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. 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 handleEvent(
) 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 values. 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 current 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 important. 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
buttons 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 keyboard 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 simulate 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 16-4. This applet allows the user to
produce simple drawings by scribbling with the mouse. It also allows
the user to erase those drawings by clicking on a button or typing
the E key. As you'll see, the applet overrides
methods to handle mouse events, keyboard events, and action events
generated by the Button component. In particular,
note the boolean return values of these
event-handling methods. This applet does not define a paint(
) method. For simplicity, it does its drawing directly in
response to the events it receives and does not store the
coordinates. This means that it cannot regenerate the
user's drawing if it is scrolled off the screen and
then scrolled back on. Since the Java 1.0 event model is deprecated,
you'll see deprecation warnings when you compile
this example.

Example 16-4. Scribble.java

package je3.applet;
import java.applet.*;
import java.awt.*;
/**
* This applet lets the user scribble with the mouse.
* It demonstrates the Java 1.0 event model.
**/
public class Scribble extends Applet {
private int lastx, lasty;    // Remember last mouse coordinates.
Button erase_button;         // The Erase button.
/** Initialize the erase button, ask for keyboard focus */
public void init( ) {
erase_button = new Button("Erase");  
this.add(erase_button);
this.setBackground(Color.white);  // Set background color for scribble
this.requestFocus( );  // Ask for keyboard focus so we get key events
}
/** Respond to mouse clicks */
public boolean mouseDown(Event e, int x, int y) {
lastx = x; lasty = y;             // Remember where the click was
return true;
}
/** Respond to mouse drags */
public boolean mouseDrag(Event e, int x, int y) {
Graphics g = getGraphics( );
g.drawLine(lastx, lasty, x, y);   // Draw from last position to here
lastx = x; lasty = y;             // And remember new last position
return true;
}
/** Respond to key presses: Erase drawing when user types 'e' */
public boolean keyDown(Event e, int key) {
if ((e.id == Event.KEY_PRESS) && (key == 'e')) {
Graphics g = getGraphics( );
g.setColor(this.getBackground( ));   
g.fillRect(0, 0, bounds( ).width, bounds( ).height);
return true;
}
else return false;
}
/** Respond to Button clicks: erase drawing when user clicks button */
public boolean action(Event e, Object arg) {
if (e.target == erase_button) {
Graphics g = getGraphics( );
g.setColor(this.getBackground( ));   
g.fillRect(0, 0, bounds( ).width, bounds( ).height);
return true;
}
else return false;
}
}