Bruce Eckel’s Thinking in Java | Contents | Prev | Next |
notice that if you compile and run the applet above, nothing happens when you
press the buttons. This is where you must step in and write some code to
determine what will happen. The basis of event-driven
programming, which comprises a lot of what a GUI is about, is tying events to
code that responds to those events.
working your way this far through the book and grasping some of the
fundamentals of object-oriented programming, you might think that of course
there will be some sort of object-oriented approach to handling events. For
example, you might have to inherit each button and override some “button
pressed” method (this, it turns out, is too tedious and restrictive). You
might also think there’s some master “event” class that
contains a method for each event you want to respond to.
objects, the typical approach to handling events was the “giant switch
statement.” Each event would have a unique integer value and inside the
master event handling method you’d write a
switch
on that value.
AWT in Java 1.0
doesn’t use any object-oriented approach. Neither does it use a giant
switch
statement that relies on the assignment of numbers to events. Instead, you must
create a cascaded set of
if
statements. What you’re trying to do with the
if
statements is detect the object that was the target
of the event. That is, if you click on a button, then that particular button is
the target. Normally, that’s all you care about – if a button is
the target of an event, then it was most certainly a mouse click and you can
continue based on that assumption. However, events can contain other
information as well. For example, if you want to find out the pixel location
where a mouse click occurred so you can draw a line to that location, the
Event
object will contain the location. (You should also be aware that Java 1.0
components can be limited in the kinds of events they generate, while Java 1.1
and Swing/JFC components produce a full set of events.)
Java 1.0
AWT method where your cascaded
if
statement resides is called action( ).
Although the whole Java 1.0
Event model has been deprecated in Java 1.1,
it is still widely used for simple applets and in systems that do not yet
support Java 1.1, so I recommend you become comfortable with it, including the
use of the following
action()
method approach.
has two arguments: the first is of type Event
and contains all the information about the event that triggered this call to
action( ).
For example, it could be a mouse click, a normal keyboard press or release, a
special key press or release, the fact that the component got or lost the
focus, mouse movements, or drags, etc. The second argument is usually the
target of the event, which you’ll often ignore. The second argument is
also encapsulated in the
Event
object so it is redundant as an argument.
situations in which
action( )
gets
called are extremely limited: When you place controls on a form, some types of
controls (buttons, check boxes, drop-down lists, menus) have a “standard
action” that occurs, which causes the call to
action( )
with the appropriate
Event
object. For example, with a button the
action( )
method is called when the button is pressed and at no other time. Usually this
is just fine, since that’s what you ordinarily look for with a button.
However, it’s possible to deal with many other types of events via the handleEvent( )
method as we will see later in this chapter.
previous example can be extended to handle button clicks as follows:
//: Button2.java // Capturing button presses import java.awt.*; import java.applet.*; public class Button2 extends Applet { Button b1 = new Button("Button 1"), b2 = new Button("Button 2"); public void init() { add(b1); add(b2); } public boolean action(Event evt, Object arg) { if(evt.target.equals(b1)) getAppletContext().showStatus("Button 1"); else if(evt.target.equals(b2)) getAppletContext().showStatus("Button 2"); // Let the base class handle it: else return super.action(evt, arg); return true; // We've handled it here } } ///:~
see what the target
is, ask the
Event
object what its
target
member is and then use the equals( )
method to see if it matches the target object handle you’re interested
in. When you’ve written handlers for all the objects you’re
interested in you must call super.action(evt,
arg)
in the
else
statement at the end, as shown above. Remember from Chapter 7 (polymorphism)
that your overridden method is called instead of the base class version.
However, the base-class version contains code to handle all of the cases that
you’re not interested in, and it won’t get called unless you call
it explicitly. The return value indicates whether you’ve handled it or
not, so if you do match an event you should return
true,
otherwise return whatever the base-class
event( )
returns.
this example, the simplest action is to print what button is pressed. Some
systems allow you to pop up a little window with a message in it, but applets
discourage this. However, you can put a message at the bottom of the Web
browser window on its
status
line
by calling the
Applet
method getAppletContext( )
to get access to the browser and then showStatus( )
to put a string on the status line.
[56]
You can print out a complete description of an event the same way, with
getAppletContext().showStatus(evt
+ “” ).
(The
empty
String
forces the compiler to convert
evt
to a
String.)
Both of these reports are really useful only for testing and debugging since
the browser might overwrite your message.
as it might seem, you can also match
an event to the
text
that’s on a button through the second argument in
event( ).
Using this technique, the example above becomes:
//: Button3.java // Matching events on button text import java.awt.*; import java.applet.*; public class Button3 extends Applet { Button b1 = new Button("Button 1"), b2 = new Button("Button 2"); public void init() { add(b1); add(b2); } public boolean action (Event evt, Object arg) { if(arg.equals("Button 1")) getAppletContext().showStatus("Button 1"); else if(arg.equals("Button 2")) getAppletContext().showStatus("Button 2"); // Let the base class handle it: else return super.action(evt, arg); return true; // We've handled it here } } ///:~
difficult to know exactly what the
equals( )
method is doing here. The biggest problem with this approach is that most new
Java programmers who start with this technique spend at least one frustrating
session discovering that they’ve gotten the capitalization or spelling
wrong when comparing to the text on a button. (I had this experience.) Also, if
you change the text of the button, the code will no longer work (but you
won’t get any compile-time or run-time error messages). You should avoid
this approach if possible.
ShowStatus( )
is also a method of Applet, so you can call it directly, without calling
getAppletContext( ).