Java Notes
Top-level Listeners
Using this as a listener
A common way to write simple applets is to use the
use the applet itself as a listener (referred to as this
).
For example
...
public class Hello extends JApplet implements ActionListener {
JButton b;
...
public void init() {
JButton b = new JButton("Hello");
b.addActionListener(this);
...
}
public void actionPerformed(ActionEvent e) {
message = "Hi";
repaint();
}
...
}
This doesn't seem to be a problem for small programs, but what happens if there
is more than one button? There can be only one actionPerformed()
method in a class.
Problem: One listener for many components
Inside the listener method, it's possible to check the parameter to find out which component caused the event. For example,
JButton b1, b2; . . . public MyClass() { // constructor ... b1.addActionListener(this); ... b2.addActionListener(this); // SAME listener! ... }//end constructor public void actionPerformed(ActionEvent e) { Object obj = e.getSource(); // get the control that caused the event if (o instanceof JButton) { // make sure it's a button. JButton b = (JButton)obj; // downcast to a button if (b == b1) { // UGLY, DON'T DO THIS // do something for button b1 } else if (b == b2) { // do something for button b2 } } else if (o instanceof JTextField) { ... ...
Using one listener makes the response slower, and forces all events to be handled in the same place. This uses the event model which was introduced in Java 1.1, but it has all the problems of the old Java 1.0 event model. Altho you will see this style used in some Java books, don't use it. It doesn't scale up from one control to many. Buttons, menu items, toolbar items, etc use action listeners; imagine what this method would look like for Microsoft Word!
Grouping all separate action listeners together in the source code is a good idea to make the code more comprehensible, but don't try to put all processing in one method!
Solution: Use inner class listeners
See Anonymous Listeners.