Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Sprachbeschreibung
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Exceptions
7 Generics<T>
8 Äußere.innere Klassen
9 Besondere Klassen der Java SE
10 Architektur, Design und angewandte Objektorientierung
11 Die Klassenbibliothek
12 Bits und Bytes und Mathematisches
13 Datenstrukturen und Algorithmen
14 Threads und nebenläufige Programmierung
15 Raum und Zeit
16 Dateien, Verzeichnisse und Dateizugriffe
17 Datenströme
18 Die eXtensible Markup Language (XML)
19 Grafische Oberflächen mit Swing
20 Grafikprogrammierung
21 Netzwerkprogrammierung
22 Verteilte Programmierung mit RMI
23 JavaServer Pages und Servlets
24 Datenbankmanagement mit JDBC
25 Reflection und Annotationen
26 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort
Ihre Meinung?

Spacer
 <<   zurück
Java ist auch eine Insel von Christian Ullenboom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
geb., mit DVD
1482 S., 49,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1506-0
Pfeil 19 Grafische Oberflächen mit Swing
  Pfeil 19.1 Das Abstract Window Toolkit und Swing
    Pfeil 19.1.1 SwingSet-Demos
    Pfeil 19.1.2 Abstract Window Toolkit (AWT)
    Pfeil 19.1.3 Java Foundation Classes
    Pfeil 19.1.4 Was Swing von AWT unterscheidet
  Pfeil 19.2 Mit NetBeans zur ersten Oberfläche
    Pfeil 19.2.1 Projekt anlegen
    Pfeil 19.2.2 Gui-Klasse hinzufügen
    Pfeil 19.2.3 Programm starten
    Pfeil 19.2.4 Grafische Oberfläche aufbauen
    Pfeil 19.2.5 Swing-Komponenten-Klassen
    Pfeil 19.2.6 Funktionalität geben
  Pfeil 19.3 Fenster unter grafischen Oberflächen
    Pfeil 19.3.1 Swing-Fenster mit javax.swing.JFrame darstellen
    Pfeil 19.3.2 Fenster schließbar machen – setDefaultCloseOperation()
    Pfeil 19.3.3 Sichtbarkeit des Fensters
    Pfeil 19.3.4 Größe und Position des Fensters verändern
    Pfeil 19.3.5 Fenster- und Dialog-Dekoration, Transparenz *
    Pfeil 19.3.6 Dynamisches Layout während einer Größenänderung *
  Pfeil 19.4 Beschriftungen (JLabel)
    Pfeil 19.4.1 Mehrzeiliger Text, HTML in der Darstellung
  Pfeil 19.5 Icon und ImageIcon für Bilder auf Swing-Komponenten
    Pfeil 19.5.1 Die Klasse ImageIcon
    Pfeil 19.5.2 Die Schnittstelle Icon und eigene Icons *
  Pfeil 19.6 Es tut sich was – Ereignisse beim AWT
    Pfeil 19.6.1 Swings Ereignisquellen und Horcher (Listener)
    Pfeil 19.6.2 Listener implementieren
    Pfeil 19.6.3 Listener bei dem Ereignisauslöser anmelden/abmelden
    Pfeil 19.6.4 Aufrufen der Listener im AWT-Event-Thread
    Pfeil 19.6.5 Adapterklassen nutzen
    Pfeil 19.6.6 Innere Mitgliedsklassen und innere anonyme Klassen
    Pfeil 19.6.7 Ereignisse etwas genauer betrachtet *
  Pfeil 19.7 Schaltflächen
    Pfeil 19.7.1 Normale Schaltflächen (JButton)
    Pfeil 19.7.2 Der aufmerksame »ActionListener«
    Pfeil 19.7.3 Schaltflächen-Ereignisse vom Typ »ActionEvent«
    Pfeil 19.7.4 Basisklasse »AbstractButton«
    Pfeil 19.7.5 Wechselknopf (JToggleButton)
  Pfeil 19.8 Swing Action *
  Pfeil 19.9 JComponent und Component als Basis aller Komponenten
    Pfeil 19.9.1 Hinzufügen von Komponenten
    Pfeil 19.9.2 Tooltips (Kurzhinweise)
    Pfeil 19.9.3 Rahmen (Border) *
    Pfeil 19.9.4 Fokus und Navigation *
    Pfeil 19.9.5 Ereignisse jeder Komponente *
    Pfeil 19.9.6 Die Größe und Position einer Komponente *
    Pfeil 19.9.7 Komponenten-Ereignisse *
    Pfeil 19.9.8 Undurchsichtige (opake) Komponente *
    Pfeil 19.9.9 Properties und Listener für Änderungen *
  Pfeil 19.10 Container
    Pfeil 19.10.1 Standardcontainer (JPanel)
    Pfeil 19.10.2 Bereich mit automatischen Rollbalken (JScrollPane)
    Pfeil 19.10.3 Reiter (JTabbedPane)
    Pfeil 19.10.4 Teilungs-Komponente (JSplitPane)
  Pfeil 19.11 Alles Auslegungssache: die Layoutmanager
    Pfeil 19.11.1 Übersicht über Layoutmanager
    Pfeil 19.11.2 Zuweisen eines Layoutmanagers
    Pfeil 19.11.3 Im Fluss mit FlowLayout
    Pfeil 19.11.4 BoxLayout
    Pfeil 19.11.5 Mit BorderLayout in alle Himmelsrichtungen
    Pfeil 19.11.6 Rasteranordnung mit GridLayout
    Pfeil 19.11.7 Der GridBagLayoutmanager *
    Pfeil 19.11.8 Null-Layout *
    Pfeil 19.11.9 Weitere Layoutmanager
  Pfeil 19.12 Rollbalken und Schieberegler
    Pfeil 19.12.1 Schieberegler (JSlider)
    Pfeil 19.12.2 Rollbalken (JScrollBar) *
  Pfeil 19.13 Kontrollfelder, Optionsfelder, Kontrollfeldgruppen
    Pfeil 19.13.1 Kontrollfelder (JCheckBox)
    Pfeil 19.13.2 ItemSelectable, ItemListener und das ItemEvent
    Pfeil 19.13.3 Sich gegenseitig ausschließende Optionen (JRadioButton)
  Pfeil 19.14 Fortschritte bei Operationen überwachen *
    Pfeil 19.14.1 Fortschrittsbalken (JProgressBar)
    Pfeil 19.14.2 Dialog mit Fortschrittsanzeige (ProgressMonitor)
  Pfeil 19.15 Menüs und Symbolleisten
    Pfeil 19.15.1 Die Menüleisten und die Einträge
    Pfeil 19.15.2 Menüeinträge definieren
    Pfeil 19.15.3 Einträge durch Action-Objekte beschreiben
    Pfeil 19.15.4 Mit der Tastatur: Mnemonics und Shortcut
    Pfeil 19.15.5 Der Tastatur-Shortcut (Accelerator)
    Pfeil 19.15.6 Tastenkürzel (Mnemonics)
    Pfeil 19.15.7 Symbolleisten alias Toolbars
    Pfeil 19.15.8 Popup-Menüs
  Pfeil 19.16 Das Model-View-Controller-Konzept
  Pfeil 19.17 Auswahlmenüs, Listen und Spinner
    Pfeil 19.17.1 Auswahlmenü (JComboBox)
    Pfeil 19.17.2 Zuordnung einer Taste mit einem Eintrag *
    Pfeil 19.17.3 Datumsauswahl
    Pfeil 19.17.4 Listen (JList)
    Pfeil 19.17.5 Drehfeld (JSpinner) *
  Pfeil 19.18 Textkomponenten
    Pfeil 19.18.1 Text in einer Eingabezeile
    Pfeil 19.18.2 Die Oberklasse der Text-Komponenten (JTextComponent)
    Pfeil 19.18.3 Geschützte Eingaben (JPasswordField)
    Pfeil 19.18.4 Validierende Eingabefelder (JFormattedTextField)
    Pfeil 19.18.5 Einfache mehrzeilige Textfelder (JTextArea)
    Pfeil 19.18.6 Editor-Klasse (JEditorPane) *
  Pfeil 19.19 Tabellen (JTable)
    Pfeil 19.19.1 Ein eigenes Tabellen-Model
    Pfeil 19.19.2 Basisklasse für eigene Modelle (AbstractTableModel)
    Pfeil 19.19.3 Vorgefertigtes Standard-Modell (DefaultTableModel)
    Pfeil 19.19.4 Ein eigener Renderer für Tabellen
    Pfeil 19.19.5 Zell-Editoren
    Pfeil 19.19.6 Größe und Umrandung der Zellen *
    Pfeil 19.19.7 Spalteninformationen*
    Pfeil 19.19.8 Tabellenkopf von Swing-Tabellen *
    Pfeil 19.19.9 Selektionen einer Tabelle *
    Pfeil 19.19.10 Automatisches Sortieren und Filtern mit RowSorter *
  Pfeil 19.20 Bäume (JTree)
    Pfeil 19.20.1 JTree und sein TreeModel und TreeNode
    Pfeil 19.20.2 Selektionen bemerken
    Pfeil 19.20.3 Das TreeModel von JTree *
  Pfeil 19.21 JRootPane und JDesktopPane *
    Pfeil 19.21.1 Wurzelkomponente der Top-Level-Komponenten (JRootPane)
    Pfeil 19.21.2 JDesktopPane und die Kinder JInternalFrame
    Pfeil 19.21.3 JLayeredPane
  Pfeil 19.22 Dialoge und Window-Objekte
    Pfeil 19.22.1 JWindow und JDialog
    Pfeil 19.22.2 Modal oder nicht-modal
    Pfeil 19.22.3 Standarddialoge mit JOptionPane
    Pfeil 19.22.4 Der Dateiauswahldialog
    Pfeil 19.22.5 Der Farbauswahldialog JColorChooser *
  Pfeil 19.23 Flexibles Java-Look-and-Feel
    Pfeil 19.23.1 Look and Feel global setzen
    Pfeil 19.23.2 UIManager
    Pfeil 19.23.3 Windowsoptik mit JGoodies Looks verbessern *
  Pfeil 19.24 Swing-Komponenten neu erstellen oder verändern *
  Pfeil 19.25 Die Zwischenablage (Clipboard)
    Pfeil 19.25.1 Clipboard-Objekte
    Pfeil 19.25.2 Auf den Inhalt zugreifen mit »Transferable«
    Pfeil 19.25.3 DataFlavor ist das Format der Daten in der Zwischenablage
    Pfeil 19.25.4 Einfügungen in der Zwischenablage erkennen
    Pfeil 19.25.5 Drag
  Pfeil 19.26 AWT, Swing und die Threads
    Pfeil 19.26.1 Ereignisschlange (EventQueue) und AWT-Event-Thread
    Pfeil 19.26.2 Swing ist nicht thread-sicher
    Pfeil 19.26.3 »invokeLater()« und »invokeAndWait()«
    Pfeil 19.26.4 SwingWorker
    Pfeil 19.26.5 Eigene Ereignisse in die Queue setzen *
    Pfeil 19.26.6 Auf alle Ereignisse hören *
  Pfeil 19.27 Barrierefreiheit mit der Java Accessibility API
  Pfeil 19.28 Zeitliches Ausführen mit dem javax.swing.Timer
  Pfeil 19.29 Zum Weiterlesen


Rheinwerk Computing - Zum Seitenanfang

19.6 Es tut sich was – Ereignisse beim AWT  Zur nächsten ÜberschriftZur vorigen Überschrift

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


Rheinwerk Computing - Zum Seitenanfang

19.6.1 Swings Ereignisquellen und Horcher (Listener)  Zur nächsten ÜberschriftZur vorigen Überschrift

Im Ereignismodell von Java 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 anklickt, aber auch auf eigene Auslöser zurückzuführen sein. Es gibt eine Reihe von Interessenten, die gern 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, wenn sie ein Ereignis aussendet. [Das ist so, als ob ich einer Frau, die ich gerade kennengelernt habe, meine Telefonnummer hinterlasse. Anstatt sie ewig anzurufen, warte ich. Wenn sie Interesse hat, wird sie sich melden. ] 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, heißt er auch Listener oder Horcher. Für jedes Ereignis gibt es einen eigenen Listener, an den das Ereignis weitergeleitet wird – darum der Name für das Modell: Delegation Model (die Entwickler hatten vorher den Namen »Command Model« vergeben, doch drückte dies die Arbeitsweise nicht richtig aus). Die folgende Tabelle gibt eine Übersicht über einige Listener und was sie für Ereignisse melden.


Tabelle 19.1  Listener und die von ihnen gemeldeten Ereignisse

Listener Ereignisse

ActionListener

Der Benutzer aktiviert eine Schaltfläche bzw. ein Menü oder drückt Enter auf einem Textfeld.

WindowListener

Der Benutzer schließt ein Fenster oder möchte es verkleinern.

MouseListener

Druck auf einen Mausknopf

MouseMotionListener

Bewegung der Maus


Dem Listener übergibt das Grafiksystem jeweils ein Ereignis-Objekt, also dem ActionListener ein ActionEvent-Objekt, dem WindowListener ein WindowEvent-Objekt usw. Die Einzigen, die etwas aus der Reihe tanzen, sind MouseListener und MouseMotionListener, denn beide melden MouseEvent-Objekte.


Rheinwerk Computing - Zum Seitenanfang

19.6.2 Listener implementieren  Zur nächsten ÜberschriftZur vorigen Überschrift

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

Eine Klasse implementiert die Schnittstelle »WindowListener«

Um ein Fenster korrekt zu schließen, ist das WindowListener-Interface zu implementieren. Dafür bieten sich zwei Möglichkeiten:

  • Eine Klasse, die zum Beispiel JFrame erweitert, implementiert gleichzeitig WindowListener.
  • Eine ganz neue Klasse implementiert die Listener-Schnittstelle.

Während der zweite Fall im Allgemeinen der bessere ist, hat die erste Variante den Vorteil, dass der Listener leicht auf Zustände oder Variablen zugreifen kann.

Wir wollen im folgenden Beispiel unser Hauptprogramm die Schnittstelle WindowListener implementieren lassen:

Listing 19.6  com/tutego/insel/ui/event/CloseWindowImplementsAll.java

package com.tutego.insel.ui.event;

import javax.swing.*;
import java.awt.event.*;

public class CloseWindowImplementsAll extends JFrame implements WindowListener
{
  // Implement WindowListener

  @Override public void windowClosing( WindowEvent event )
  {
   System.exit( 0 );
  }

  @Override public void windowClosed( WindowEvent event ) { /*Empty*/ }
  @Override public void windowDeiconified( WindowEvent event ) { /*Empty*/ }
  @Override public void windowIconified( WindowEvent event ) { /*Empty*/ }
  @Override public void windowActivated( WindowEvent event ) { /*Empty*/ }
  @Override public void windowDeactivated( WindowEvent event ) { /*Empty*/ }
  @Override public void windowOpened( WindowEvent event ) { /*Empty*/ }

  //

  public CloseWindowImplementsAll()
  {
    setSize( 400, 400 );
    addWindowListener( this );
    setVisible( true );
  }

  public static void main( String[] args )
  {
    new CloseWindowImplementsAll();
  }
}

An diesem Beispiel ist abzulesen, dass jeder, der ein WindowListener sein möchte, die vorgeschriebene Methode implementieren muss. Damit zeigt er Interesse an dem WindowEvent. Bis auf windowClosing() haben wir die anderen Operationen nicht implementiert, da sie uns nicht interessieren. Die Implementierung ist so, dass die Anwendung beendet wird, wenn der Anwender auf das × klickt.


interface java.awt.event.WindowListener
extends EventListener

  • void windowOpened( WindowEvent e ) Wird aufgerufen, wenn das Fenster geöffnet wurde.
  • void windowClosing( WindowEvent e ) Wird aufgerufen, wenn das Fenster geschlossen wird.
  • void windowClosed( WindowEvent e ) Wird aufgerufen, wenn das Fenster mit dispose() geschlossen wurde.
  • void windowIconified( WindowEvent e ) Wird aufgerufen, wenn das Fenster zum Icon verkleinert wird.
  • void windowDeiconified( WindowEvent e ) Wird aufgerufen, wenn das Fenster wieder hochgeholt wird.
  • void windowActivated( WindowEvent e ) Wird aufgerufen, wenn das Fenster aktiviert wird.
  • void windowDeactivated( WindowEvent e ) Wird aufgerufen, wenn das Fenster deaktiviert wird.

Rheinwerk Computing - Zum Seitenanfang

19.6.3 Listener bei dem Ereignisauslöser anmelden/abmelden  Zur nächsten ÜberschriftZur vorigen Überschrift

Hat der Listener die Schnittstelle implementiert, wird er mit dem Ereignisauslöser verbunden. Dafür gibt es eine Reihe von Hinzufügen- und Entfernen-Methoden, die einer Namenskonvention folgen.

  • addEreignisListener( EreignisListener )
  • removeEreignisListener( EreignisListener )

Dies bedeutet, dass etwa ein Listener für Fenster-Ereignisse, ein WindowListener, der WindowEvent-Ereignisse auslöst, mit der Methode addWindowListener() an das Fenster gebunden wird. Üblicherweise lassen sich beliebig viele Listener an einen Ereignisauslöser hängen:

Listing 19.7  CloseWindowImplementsAll.java, CloseWindowImplementsAll()

  CloseWindowImplementsAll()
  {
    setSize( 400, 400 );
    addWindowListener( this );
    setVisible( true );
  }

Wir tragen mit addWindowListener() den Listener (bei this das eigene Objekt als Listener) in eine interne Liste ein. Immer wenn ein Event ausgelöst wird, kümmert sich die jeweilige Methode um dessen Abarbeitung.

Natürlich kann nicht jede Komponente jedes Ereignis auslösen. Daher gibt es nur Hinzufügemethoden für Ereignisse, die die Komponenten tatsächlich auslösen. Ein Fenster wird zum Beispiel kein ActionEvent auslösen, daher fehlt ihm eine Methode addActionListener(). Dafür kann ein Fenster Fenster-Ereignisse auslösen und besitzt eine Methode addWindowListener(). Eine Schaltfläche wiederum löst keine Fenster-Ereignisse aus, und daher gibt es die Methode addWindowListener() bei Schaltflächen nicht. So lassen sich über die angebotenen addXXXListener()-Methoden gut die Ereignisse ablesen, die eine Komponente auslösen kann, denn das XXX wird dann nach der Namenskonvention der Ereignis-Typ sein.


Rheinwerk Computing - Zum Seitenanfang

19.6.4 Aufrufen der Listener im AWT-Event-Thread  Zur nächsten ÜberschriftZur vorigen Überschrift

Nachdem der Listener implementiert und angemeldet wurde, ist das System im Fall eines aufkommenden Ereignisses bereit, es zu verteilen. Aktiviert zum Beispiel der Benutzer eine Schaltfläche, so führt der AWT-Event-Thread – auch Event-Dispatching-Thread genannt – den Programmcode im Listener selbstständig aus. Sehr wichtig ist Folgendes: Der Programmcode im Listener sollte nicht zu lange dauern, da sich sonst Ereignisse in der Queue sammeln, die der AWT-Thread nicht mehr verarbeiten kann. Diese Eigenschaft fällt dann schnell auf, wenn sich Aufforderungen zum Neuzeigen (Repaint-Ereignisse) aufstauen, da auf diese Weise leicht ein »stehendes System« entsteht.

Die Reihenfolge, in der die Listener abgearbeitet werden, ist im Prinzip undefiniert. Zwar reiht das JDK es in eine Liste ein, sodass es dadurch eine Reihenfolge gibt, doch sollte diesem Implementierungsdetail keine Beachtung geschenkt werden.


Rheinwerk Computing - Zum Seitenanfang

19.6.5 Adapterklassen nutzen  Zur nächsten ÜberschriftZur vorigen Überschrift

Der Nachteil der ersten Variante besteht darin, dass wir immer alle Methoden implementieren müssen, auch wenn wir nur eine der vielen Methoden 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 19.8  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 jetzt keine Rolle spielen.

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 19.9  com/tutego/insel/ui/event/CloseWindowWithAdapter.java

package com.tutego.insel.ui.event;

import java.awt.event.*;
import javax.swing.*;

public class CloseWindowWithAdapter
{
  public static void main( String[] args )
  {
    JFrame f = new JFrame();
    f.setSize( 400, 400 );
    f.setVisible( true );

    f.addWindowListener( new CloseWindowAction() );
  }
}

class CloseWindowAction extends WindowAdapter
{
  @Override
  public void windowClosing( WindowEvent e ) { System.exit(0); }
}

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 einen Aufruf von System.exit(), um die Applikation zu beenden, da windowClosing() immer bei Beendigung der Applikation mit dem ´ am Fenster aufgerufen wird. Was allerdings leicht vergessen wird, ist die Tatsache, dass nicht nur der Benutzer über das ´ 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 ´ und durch dispose() unterscheiden können, kümmert sich windowClosing() um das ´ und windowClosed() um das dispose(). Wenn wir lediglich mit dem ´ 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 ´ 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.
  }
}

»setDefaultCloseOperation()« und der WindowListener *

Die Anweisung setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) ist eigentlich nur zu Testzwecken nützlich, denn in ausgewachsenen GUI-Anwendungen sollte sich die Applikation nicht einfach schließen, sondern mit einem Dialog über das Ende informieren. Hier werden nun die Konstanten HIDE_ON_CLOSE und DISPOSE_ON_CLOSE für die setDefaultCloseOperation() interessant. Sie kennzeichnen zum einen, ob das Fenster automatisch verdeckt werden soll, nachdem die WindowListener aufgerufen wurden (dies ist der Standard), und zum anderen, ob alle Listener abgearbeitet werden sollen und das Fenster geschlossen werden soll. HIDE_ON_CLOSE ist die Standardeinstellung.


Rheinwerk Computing - Zum Seitenanfang

19.6.6 Innere Mitgliedsklassen und innere anonyme Klassen  Zur nächsten ÜberschriftZur vorigen Überschrift

Wir haben für die Adapterklasse eine externe Klasse benutzt, weil das Erweitern wegen der Einfachvererbung schnell an seine Grenzen stößt. Mit inneren Klassen wird allerdings alles elegant, denn sie können leicht auf Zustände der äußeren Klasse zugreifen. Dabei lassen sich innere Klassen auf unterschiedliche Weise verwenden. Zum einen als Mitgliedsklasse; das heißt, die Klasse, die bisher als externe Klasse vorgelegen hat, wird in eine andere Klasse hineingenommen. Im vorigen Beispiel bedeutet dies: Wir nehmen CloseWindowAction in die Klasse CloseWindowWithAdapter auf und schreiben die Klassendeklaration nicht unter der anderen Klasse. Zum anderen kann die innere Klasse wie eine lokale Variablendeklaration noch in die Methode aufgenommen werden, die die addXXXListener()-Methode 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. Implementieren wir unser Programm zum Schließen des Fensters mit einer inneren anonymen Klasse:

Listing 19.10  com/tutego/insel/ui/event/CloseWindowWithInnerClass.java

package com.tutego.insel.ui.event;

import java.awt.event.*;
import javax.swing.*;

public class CloseWindowWithInnerClass extends JFrame
{
  public CloseWindowWithInnerClass()
  {
    setSize( 400, 400 );

    addWindowListener( new WindowAdapter() {
      @Override public void windowClosing( WindowEvent e ) {
        System.exit( 0 );
      }
    } );
  }

  public static void main( String[] args )
  {
    new CloseWindowWithInnerClass().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.


Rheinwerk Computing - Zum Seitenanfang

19.6.7 Ereignisse etwas genauer betrachtet *  topZur vorigen Überschrift

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.

»AWTEvent« und Unterklassen (wie »WindowEvent«, »KeyEvent«)

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 die meisten Oberflächen-Ereignis-Klassen in dem Unterpaket java.awt.event befinden, ist AWTEvent selbst direkt unter java.awt und damit nicht im Ereignis-Paket.

Eine wichtige Methode ist getID(). Jede Ereignis-Klasse definiert eine ID, durch die sich die Ereignisse neben ihrer Klassenzugehörigkeit unterscheiden. 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 sein soll, weil die Vererbungsbeziehung doch den Typ klärt. 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, das 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. Statt einer neuen Klasse wird der Typ als eigenes Attribut im KeyEvent gespeichert.

Events auf verschiedenen Ebenen

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

  • Ereignisse auf niedriger Ebene (engl. low-level events): Damit sind Ereignisse auf der Ebene des grafischen Betriebssystems gemeint. Das sind etwa eine Mausbewegung oder ein Fokus auf Komponenten, Tastendrücke oder das Schließen oder Vergrößern eines Fensters.
  • Ereignisse auf höherer Ebene, semantische Ereignisse (engl. high-level events): Auf der anderen Seite gibt es Ereignisse, die von GUI-Komponenten erzeugt werden, wenn etwa eine Schaltfläche aktiviert (etwa durch Mausklick oder Drücken der Enter -Taste) oder ein Rollbalken bewegt wird (zum Beispiel durch die Maus oder durch die Bild-hoch -Taste). Die Swing-Komponenten reagieren meistens auf Ereignisse niedriger Ebene und formulieren daraus ein semantisches Ereignis. Es ist selten nötig, auf niedrige Ereignisse zu hören.

Die Trennung fällt aber nicht weiter auf, sodass wir im Folgenden darauf 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.


Tabelle 19.2  Ereignisklassen und ihre IDs

Klasse ID

ComponentEvent

COMPONENT_MOVED, COMPONENT_RESIZED, COMPONENT_SHOWN, COMPONENT_HIDDEN

FocusEvent

FOCUS_GAINED, FOCUS_LOST

KeyEvent

KEY_PRESSED, KEY_RELEASED, KEY_TYPED

MouseEvent

MOUSE_CLICKED, MOUSE_DRAGGED, MOUSE_ENTERED, MOUSE_EXITED, MOUSE_MOVED, MOUSE_PRESSED, MOUSE_RELEASED

HierarchyEvent

ANCESTOR_MOVED, ANCESTOR_RESIZED, DISPLAYABILITY_CHANGED, HIERARCHY_CHANGED, PARENT_CHANGED SHOWING_CHANGED

InputMethodEvent

CARET_POSITION_CHANGED, INPUT_METHOD_TEXT_CHANGED


Weitere Ereignisse auf niedriger Ebene werden von Fenstern und Dialogen ausgelöst; sie senden Ereignisobjekte vom Typ WindowEvent. Wir werden uns in diesem Kapitel auch mit den unterschiedlichen Komponenten beschäftigen und 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.


Tabelle 19.3  Einige Ereignisauslöser

Auslöser Wann das Event ausgelöst wird Ereignis

JButton

Aktivierung der Schaltfläche

ActionEvent

JScrollBar

Wertänderung

AdjustmentEvent

JTextComponent

Verschiebung des Cursors

CaretEvent

JSlider

Änderung der Werte

ChangeEvent

Component

Änderung der Sichtbarkeit oder Größe

ComponentEvent

Container

Änderung des Inhalts

ContainerEvent

JComponent

neuer Fokus (bei Tastatureingaben)

FocusEvent

JEditorPane

Hyperlink-Auswahl

HyperlinkEvent

JList

Auswahl

ItemEvent

JComponent

Tastatur

KeyEvent

JMenu

Menüauswahl

MenuEvent

JComponent

Betreten oder Verlassen einer Komponente

MouseEvent

JComponent

Bewegung

MouseMotionEvent

JWindow

Zustandsänderung

WindowEvent

Eye

Augenzwinkern [Frauen zwinkern doppelt so häufig wie Männer.]

EyelidEvent




Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
 <<   zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Java SE Bibliotheken






 Java SE Bibliotheken


Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Einstieg in Eclipse






 Einstieg in
 Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in
 Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de