15.2 Varianten, das Fenster zu schließen 

Bei dem ersten AWT-Programm mit Fenstern haben wir das Problem, dass das Fenster nicht sauber geschlossen werden kann. Dies liegt ganz einfach daran, dass spezielle Fensterereignisse ausgelöst werden, die von uns abgefangen werden müssen, was wir aber nicht getan haben. Doch nur dann ist ein sauberes Beenden möglich, denn bei den vielen Ereignissen, die das Fenstersystem sendet, ist auch die Aufforderung zum Schließen des Fensters dabei. 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 dann, wenn ein Event ausgelöst wird, kümmert sich diese jeweilige Funktion um die 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. Dazu bieten sich zwei Klassen an: zum einen die Hauptklasse, die auch das Fenster öffnet, und zum anderen eine externe Klasse, die nichts anderes macht, 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, aber die Funktion lässt sich 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 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, die 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. Denn windowClosing() wird immer dann aufgerufen, wenn die Applikation mit dem X am Fenster beendet wird. Was allerdings leicht vergessen wird, ist, 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 so 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, so ist es sinnvoll, in windowClosing() mit dispose() indirekt windowClosed() aufzurufen. Das sieht dann so 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. Sie sind 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 kommen, sondern noch von zwei weiteren Schnittstellen, die in 1.4 hinzugekommen sind.

Hier klicken, um das Bild zu Vergrößern

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
{
  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, denn das Erweitern stößt wegen der Einfachvererbung schnell an seine Grenzen. Mit inneren Klassen wird das Ganze allerdings elegant. Dabei lassen sich innere Klassen auf unterschiedliche Weise verwenden. Einmal als Mitgliedsklasse, das heißt, die Klasse, die bisher als externe Klasse vorlag, wird in eine andere Klasse hineingenommen. In dem gerade gezeigten Beispiel heißt das, 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 addXXXListener()-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.

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() {  
        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 macht nur hier Sinn 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:

http://java.sun.com/products/jfc/tsc/articles/generic-listener2/index.html

http://java.sun.com/products/jfc/tsc/articles/generic-listener/index.html

Von dort kann auch die allgemeine Implementierung für eine Klasse GenericListener bezogen werden.