Kapitel 15 Komponenten, Container und Ereignisse

Wenn die Reklame keinen Erfolg hat,
muss man die Ware ändern.
– Faure

15.1 Es tut sich was – Ereignisse beim AWT 

15.1.1 Was ist ein Ereignis? 

Beim Arbeiten mit grafischen Oberflächen interagiert der Benutzer mit Komponenten. Er bewegt die Maus im Fenster, drückt eine Schaltfläche oder verschiebt einen Schieberegler. Das grafische System beobachtet die Aktionen der Benutzer und informiert die Applikation über die anfallenden Ereignisse. Dann kann das laufende Programm entsprechend reagieren.

15.1.2 Die Klasse AWTEvent 

Die ausgesandten Botschaften werden in Ereignis-Klassen kategorisiert. Da es unterschiedliche Ereignisse (engl. events) gibt, kann das System somit die Ereignisse unterteilen und eine Vorauswahl treffen. Alle Ereignisse der grafischen Oberfläche sind Objekte, die aus einer Unterklasse von AWTEvent gebildet sind. Die Klasse AWTEvent ist abstrakt und selbst von EventObject aus dem util-Paket abgeleitet. Obwohl sich alle Oberflächen-Ereignis-Klassen in dem Unterpaket java.awt.event befinden, findet sich AWTEvent selbst direkt unter java.awt und damit nicht im Ereignis-Paket.

AWTEvent unter Unterklassen (wie WindowEvent, KeyEvent)

Eine wichtige Methode ist getID(). Jede Ereignis-Klasse definiert eine ID, durch die sich die Ereignisse neben ihrer Klassenzugehörigkeit unterschieden. Für Ereignisse von gedrückten Schaltflächen ist die ID etwa ActionEvent.ACTION_PERFORMED. Natürlich stellt sich die Frage, wieso eine ID für die Ereignisse notwendig ist, die Vererbungsbeziehung klärt doch den Typ. Das ist zwar korrekt, doch gäbe es für mehr als dreißig Events zu viele Klassen. Daher haben die Entwickler ähnliche Ereignisse zu Gruppen zusammengefasst. So etwa bei einem WindowEvent, welches dann versandt wird, wenn etwa das Fenster geschlossen oder verkleinert wird. In diesem Fall gibt es ein Ereignis vom Typ WindowEvent, aber zwei unterschiedliche IDs. So wird eine unübersehbare Anzahl von Event-Klassen vermieden. Einige Klassen verwalten weitere Konstanten, etwa für die gedrückten Tasten. Es wäre kaum sinnvoll, für jede Taste eine eigene Klasse zu schreiben. Diese wird als eigenes Attribut im KeyEvent gespeichert.

Hier klicken, um das Bild zu Vergrößern

15.1.3 Events auf verschiedenen Ebenen 

Bei den Ereignissen werden zwei Typen unterschieden: die Ereignisse auf niedriger und die auf hoher Ebene.

Ereignisse niedriger Ebene (engl. low level events). Damit ist gemeint, dass es Ereignisse gibt, die mit einem speziellen GUI-Element verbunden sind. Das sind etwa Mausbewegung oder Fokus auf Komponenten, Tastaturklicks oder das Schließen oder Vergrößern eines Fensters.

Ereignisse höherer Ebene, semantische Ereignisse. Auf der anderen Seite gibt es Ereignisse, die von GUI-Komponenten erzeugt werden, wenn etwa eine Schaltfläche gedrückt oder ein Schieberegler bewegt wird. Der Unterschied zu den Low-level-Events ist, dass mit unterschiedlichen Komponenten durchaus die gleichen semantischen Ereignisse verbunden sein können. So werden etwa bei der Aktivierung einer Liste oder einer Auswahlbox die gleichen Ereignisse versandt.

Die Trennung fällt aber nicht weiter auf, so dass wir im Folgenden darauf auch nicht eingehen werden.

Da alle grafischen Komponenten von der Klasse Component abgeleitet sind, liefern sie automatisch eine Reihe von nicht semantischen Ereignissen. Wir finden die Unterklassen und die Ereignistypen in der folgenden Tabelle.

Weitere niedrige Ereignisse lösen Fenster und Dialoge aus; sie senden Objekte vom Typ WindowEvent. Wir werden uns in diesem Kapitel ebenfalls mit den unterschiedlichen Komponenten beschäftigen und auch immer gleich die zugehörigen Ereignisse untersuchen. Die folgende Tabelle zeigt für einige grafische Komponenten die Ereignisse und gibt an, wann sie ausgelöst werden können.

15.1.4 Ereignisquellen, -senken und Horcher (Listener) 

Im Ereignismodell 1.1 gibt es eine Reihe von Ereignisauslösern (Ereignisquellen, engl. event source), wie zum Beispiel Schaltflächen. Die Ereignisse können von der grafischen Oberfläche kommen, etwa wenn der Benutzer eine Schaltfläche drückt. Sie können aber auch von eigenen Auslösern kommen. Es existiert eine Reihe von Interessenten, die gerne informiert werden wollen, wenn ein Ereignis aufgetreten ist. Da der Interessent in der Regel nicht an allen ausgelösten Oberflächen-Ereignissen interessiert ist, sagt er einfach, welche Ereignisse er empfangen möchte. Dies funktioniert so, dass er sich bei einer Ereignisquelle anmeldet, und diese informiert ihn dann, wenn sie ein Ereignis aussendet.¹  Auf diese Weise leidet die Systemeffizienz nicht, da nur diejenigen informiert werden, die auch Verwendung für das Ereignis haben.

Da der Interessent an der Quelle horcht, nennt er sich auch Listener oder Horcher. Es existiert für jedes Ereignis ein eigener Listener, an den das Ereignis weitergeleitet wird. Daher stammt auch der Name für das Modell: Delegation Model. (Die Entwickler hatten vorher den Namen »Command Model« vergeben, doch dies drückte die Arbeitsweise nicht richtig aus.)

15.1.5 Listener implementieren 

Der Listener selbst ist eine Schnittstelle, die von den Interessenten implementiert wird. Da jede Schnittstelle Methoden vorschreibt, muss der Interessent diese Methoden implementieren. Wird im nächsten Schritt ein Horcher mit dem Ereignisauslöser verbunden, dann kann die Ereignisquelle davon ausgehen, dass der Horcher die entsprechende Methode besitzt. Diese ruft die Quelle auf.

public interface ActionListener extends EventListener
{
  void actionPerformed( ActionEvent e );
}

Hier klicken, um das Bild zu Vergrößern

An diesem Beispiel ist abzulesen, dass jeder, der ein ActionListener sein möchte, die Methode actionPerformed() implementieren muss. Damit zeigt er Interesse an dem ActionEvent.

class ActionListenerImpl   implements ActionListener  
{
    public void actionPerformed( ActionEvent e )  
  {
    System.out.println( "Ich wurde berührt" );
  }
}

Die implementierende Klasse wird anschließend der auslösenden Komponente, also zum Beispiel einer Schaltfläche, hinzugefügt. Tritt ein Ereignis auf, ruft die Ereignisquelle auf allen registrierten Listenern die actionPerformed()-Methode auf.

15.1.6 Listener bei Ereignisauslöser anmelden/abmelden 

Hat der Listener die Schnittstelle implementiert, dann wird er mit dem Ereignisauslöser verbunden. Dafür existieren eine Reihe von Zufüge- und Entfernenmethoden, die einer Namenskonvention folgen.

addEreignisListener( Listener-Objekt )
removeEreignisListener( Listener-Objekt )

Das bedeutet, dass etwa ein Listener für Schaltflächen, ein ActionListener, der ActionEvent-Ereignisse auslöst, mit der Methode addActionListener() an die Komponenten gebunden wird. Wenn die Klasse ActionListenerImpl die Schnittstelle ActionListener implementiert und die Komponente eine Schaltfläche mit der Referenz button ist, dann ergibt sich Folgendes für die Ereignisbehandlung:

ActionListener listener = new ActionListenerImpl();
button.addActionListener( listener );

Die letzte Zeile trägt den Listener in einer internen Liste beim Button, einer Schaltfläche, ein.

15.1.7 Aufrufen der Listener 

Nach dem der Listener implementiert und angemeldet wurde ist das System im Fall eines aufkommendes Ereignisses bereit, es zu verteilen. Aktiviert zum Beispiel der Benutzer eine Schaltfläche, so führt der AWT-Event-Thread den Programmcode im Listener selbständig aus. Sehr wichtig ist Folgendes: Der Programmcode im Listener sollte nicht zu lange dauern, da sonst der AWT-Thread nicht mehr die anderen Ereignisse, die sich in einer Queue sammlen, verarbeiten kann. Dadurch entsteht leicht ein »stehendes System«.

Die Reihenfolge, in dem die Listener abgearbeitet werden, ist im Prinzip undefiniert.

¹   Das ist so, als ob ich einer Frau, die ich gerade kennen gelernt habe, meine Telefonnummer hinterlasse. Anstatt sie ewig anzurufen, warte ich. Wenn sie Interesse hat, wird sie sich melden.