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.

Table 16-1. Java 1.0 event-processing methods of Component

action( )	lostFocus( )	mouseExit( )
gotFocus( )	mouseDown( )	mouseMove( )
keyDown( )	mouseDrag( )	mouseUp( )
keyUp( )	mouseEnter( )

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;     } }