15.2 Varianten, das Fenster zu schließen
 
Beim ersten AWT-Programm mit Fenstern konnte das Fenster nicht sauber geschlossen werden. Dies liegt ganz einfach daran, dass spezielle Fensterereignisse ausgelöst werden, die wir abfangen müssen (was wir aber nicht getan haben). Nur dann ist jedoch ein sauberer Ausstieg möglich, da sich unter den vielen Ereignissen, die das Fenstersystem sendet, auch die Aufforderung zum Schließen des Fensters befindet. Unter Swing reagiert ein JFrame auf WindowEvents, reagiert in der protected-Methode processWindowEvent() auf das WINDOW_CLOSING und kann das Fenster so auch ohne hinzugefügten Ereignisbehandler schließen.
Um ein Fenster korrekt zu schließen, müssen wir das WindowListener-Interface implementieren. WindowListener definiert eine Anzahl von Funktionen, die mit addWindowListener() an ein Fenster gebunden werden. Immer wenn ein Event ausgelöst wird, kümmert sich die jeweilige Funktion um dessen Abarbeitung.
Wir wollen im Folgenden einige populäre Möglichkeiten zum Schließen eines Fensters aufzeigen.
15.2.1 Eine Klasse implementiert die Schnittstelle WindowListener
 
Die erste Möglichkeit, Ereignisbehandlung zu implementieren, besteht in der Implementierung aller vorgeschriebenen Methoden der Listener-Schnittstelle. Dafür bieten sich zwei Klassen an: zum einen die auch das Fenster öffnende Hauptklasse, und zum anderen eine externe Klasse, die nichts anderes tut, als die Listener-Schnittstelle zu implementieren. Wir wollen im folgenden Beispiel unser Hauptprogramm – die Schnittstelle WindowListener – implementieren lassen.
 Hier klicken, um das Bild zu Vergrößern
Listing 15.1
FensterWegImplementsAll.java
import javax.swing.*;
import java.awt.event.*;
class FensterWegImplementsAll extends JFrame implements WindowListener
{
public FensterWegImplementsAll()
{
setSize( 400, 400 );
addWindowListener( this );
setVisible( true );
}
// Implementiere WindowListener
public void windowClosing( WindowEvent event ) {
System.exit( 0 );
}
public void windowClosed( WindowEvent event ) {}
public void windowDeiconified( WindowEvent event ) {}
public void windowIconified( WindowEvent event ) {}
public void windowActivated( WindowEvent event ) {}
public void windowDeactivated( WindowEvent event ) {}
public void windowOpened( WindowEvent event ) {}
public static void main( String[] args )
{
new FensterWegImplementsAll();
}
}
Die anderen Funktionen sind hier nicht implementiert, doch lässt sich die Funktion leicht am Namen ablesen. Das Fenster wird geschlossen, wenn der Anwender auf das X drückt.
interface java.awt.event. WindowListener
extends EventListener
|
|
void windowOpened( WindowEvent e )
Aufgerufen, wenn das Fenster geöffnet wurde. |
|
void windowClosing( WindowEvent e )
Aufgerufen, wenn das Fenster geschlossen wird. |
|
void windowClosed( WindowEvent e )
Aufgerufen, wenn das Fenster mit dispose() geschlossen wurde. |
|
void windowIconified( WindowEvent e )
Aufgerufen, wenn das Fenster zum Icon verkleinert wird. |
|
void windowDeiconified( WindowEvent e )
Aufgerufen, wenn das Fenster wieder hochgeholt wird. |
|
void windowActivated( WindowEvent e )
Aufgerufen, wenn das Fenster aktiviert wird. |
|
void windowDeactivated( WindowEvent e )
Aufgerufen, wenn das Fenster deaktiviert wird. |
Der Unterschied zwischen windowClosing() und windowClosed()
Die Schnittstelle WindowListener schreibt zwei Methoden vor, deren Namen sich ziemlich ähnlich anhören: windowClosing() und windowClosed(). Betrachten wir den Unterschied zwischen beiden und wie ein Programm beide Methoden nutzen oder meiden kann.
In den einfachen Programmen setzen wir in die windowClosing()-Methode ein System.exit() ein, um die Applikation zu beenden, da windowClosing()immer bei Beendigung der Applikation mit dem X am Fenster aufgerufen wird. Was allerdings leicht vergessen wird, ist die Tatsache, dass nicht nur der Benutzer über das X das Fenster schließen kann, sondern auch die Applikation über die spezielle Methode dispose(). Sie gibt alle Ressourcen frei und schließt das Fenster. Die Applikation ist dann allerdings noch nicht beendet. Damit wir das Schließen mit dem X und durch dispose() unterscheiden können, kümmert sich windowClosing() um das X und windowClosed() um das dispose(). Wenn wir lediglich mit dem X das Fenster schließen und die Applikation beendet werden soll, muss nicht noch extra dispose() schön brav die Ressourcen freigeben. Daher reicht oft ein System.exit(). Soll das Fenster jedoch mit X und dispose() einfach nur geschlossen werden oder ist eine gemeinsame Behandlung gewünscht, ist es sinnvoll, in windowClosing() mit dispose() indirekt windowClosed() aufzurufen. Das sieht dann folgendermaßen aus:
class WL extends WindowAdapter
{
public void windowClosing( WindowEvent e )
{
event.getWindow().dispose();
}
public void windowClosed( WindowEvent e )
{
// Das Fenster ist geschlossen, und jetzt können wir hier
// weitermachen, etwa mit System.exit(), wenn alles
// vorbei sein soll.
}
}
15.2.2 Adapterklassen nutzen
 
Der Nachteil der ersten Variante ist, dass wir immer alle Methoden implementieren müssen, auch wenn wir nur eine der vielen Funktionen benötigen. Hier helfen Adapterklassen – Klassen, die die Schnittstellen mit leeren Rümpfen implementieren. Hat beispielsweise die Schnittstelle WindowListener sieben Methoden, so steht in der Adapterklasse folgende Implementierung:
Listing 15.2
java.awt.event.WindowAdapter
public abstract class WindowAdapter
implements WindowListener, WindowStateListener, WindowFocusListener
{
public void windowOpened(WindowEvent e) {}
public void windowClosing(WindowEvent e) {}
public void windowClosed(WindowEvent e) {}
public void windowIconified(WindowEvent e) {}
public void windowDeiconified(WindowEvent e) {}
public void windowActivated(WindowEvent e) {}
public void windowDeactivated(WindowEvent e) {}
public void windowStateChanged(WindowEvent e) {}
public void windowGainedFocus(WindowEvent e) {}
public void windowLostFocus(WindowEvent e) {}
}
Zusätzlich entdecken wir einige Methoden, die nicht direkt von unserem WindowListener stammen, sondern von zwei weiteren Schnittstellen, die in Java 1.4 hinzugekommen sind.
 Hier klicken, um das Bild zu Vergrößern
Beispiel Wenn wir jetzt einen Ereignisbehandler verwenden, erweitern wir einfach die Adapterklasse. Unser Programm zum Schließen des Fensters mit einer externen Adapterklasse sieht dann wie folgt aus:
Listing 15.3
FensterWegExternerAdapter.java
import java.awt.event.*;
import javax.swing.*;
public class FensterWegExternerAdapter
{
public static void main( String[] args )
{
JFrame f = new JFrame();
f.setSize( 400, 400 );
f.setVisible( true );
f.addWindowListener( new FensterWegAdapter() );
}
}
class FensterWegAdapter extends WindowAdapter
{
@Override
public void windowClosing( WindowEvent e ) { System.exit(0); }
}
|
15.2.3 Innere Mitgliedsklassen und innere anonyme Klassen
 
Wir haben für die Adapterklasse eine externe Klasse benutzt, das Erweitern wegen der Einfachvererbung schnell an seine Grenzen stößt. Mit inneren Klassen wird allerdings alles elegant. Dabei lassen sich innere Klassen auf unterschiedliche Weise verwenden. Einmal als Mitgliedsklasse, das heißt, die bisher als externe Klasse vorgelegene Klasse wird in eine andere Klasse hineingenommen. Im vorigen Beispiel bedeutet dies: Wir nehmen FensterWegAdapter in die Klasse FensterWegExternerAdapter auf und schreiben die Klassendefinition nicht unter der anderen Klasse. Dann kann die innere Klasse wie eine lokale Variablendeklaration noch in der Methode aufgenommen werden, die die addXXX-Listener()-Funktion beinhaltet.
Der zweite Weg führt über innere anonyme Klassen. Dadurch wird das Programm zwar schön kurz, doch lange Ereignisbehandler führen schnell zu unübersichtlichem Quellcode.
Beispiel Wir implementieren unser Programm zum Schließen des Fensters mit einer inneren anonymen Klasse.
|
Listing 15.4
FensterWegInnerAnonym.java
import java.awt.event.*;
import javax.swing.*;
public class FensterWegInnerAnonym extends JFrame
{
public FensterWegInnerAnonym()
{
setSize( 400, 400 );
addWindowListener( new WindowAdapter() {
@Override public void windowClosing ( WindowEvent e) {
System.exit( 0 );
}
} );
}
public static void main( String[] args )
{
new FensterWegInnerAnonym().setVisible( true );
}
}
Die Lösung hat den Vorteil, dass nicht extra eine eigene Klasse mit einem häufig überflüssigen Namen angelegt wird. Die Unterklasse von WindowAdapter ist nur hier sinnvoll und wird nur in diesem Kontext benötigt.
15.2.4 Generic Listener
 
Eine recht neue Methode haben die Entwickler ab Version 1.3 hinzugefügt: Generic Listener. Sie ist noch nicht sehr verbreitet, dennoch sollte sie erwähnt werden. Der Unterschied zu den bisher vorgestellten Möglichkeiten liegt darin, einem Verwalter die Ereignisquelle und das Ereignisziel vorzugeben. Das Ziel ist dabei eine beliebige Methode. Beim Auftreten eines Ereignisses findet das System automatisch mittels Reflection die von uns angegebene Methode und ruft sie auf. Bisher sind Generic Listener eine einfache Erweiterung der Proxy-Klassen und noch nicht in die Java-Standardbibliothek eingeflossen. Die Implementierung fasst jedoch mit Kommentaren nur zweihundert Zeilen. Wir werden auf Generic Listener zurückkommen, wenn wir Ereignisse von Schaltflächen kennen gelernt haben. Informationen zu den Generic Listenern gibt es auf der Web-Seite von Sun unter:
Von dort kann auch die allgemeine Implementierung für eine Klasse GenericListener bezogen werden.
|