Java SE 8 Standard-Bibliothek  
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis


Vorwort
1 Neues in Java 8 und Java 7
2 Fortgeschrittene String-Verarbeitung
3 Threads und nebenläufige Programmierung
4 Datenstrukturen und Algorithmen
5 Raum und Zeit
6 Dateien, Verzeichnisse und Dateizugriffe
7 Datenströme
8 Die eXtensible Markup Language (XML)
9 Dateiformate
10 Grafische Oberflächen mit Swing
11 Grafikprogrammierung
12 JavaFX
13 Netzwerkprogrammierung
14 Verteilte Programmierung mit RMI
15 RESTful und SOAP-Web-Services
16 Technologien für die Infrastruktur
17 Typen, Reflection und Annotationen
18 Dynamische Übersetzung und Skriptsprachen
19 Logging und Monitoring
20 Sicherheitskonzepte
21 Datenbankmanagement mit JDBC
22 Java Native Interface (JNI)
23 Dienstprogramme für die Java-Umgebung
Stichwortverzeichnis

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java SE 8 Standard-Bibliothek von Christian Ullenboom
Das Handbuch für Java-Entwickler
Buch: Java SE 8 Standard-Bibliothek

Java SE 8 Standard-Bibliothek
Pfeil 10 Grafische Oberflächen mit Swing
Pfeil 10.1 AWT, JavaFoundation Classes und Swing
Pfeil 10.1.1 Das Abstract Window Toolkit (AWT)
Pfeil 10.1.2 Java Foundation Classes (JFC)
Pfeil 10.1.3 Was Swing von AWT-Komponenten unterscheidet
Pfeil 10.2 Mit NetBeans zur ersten Swing-Oberfläche
Pfeil 10.2.1 Projekt anlegen
Pfeil 10.2.2 Eine GUI-Klasse hinzufügen
Pfeil 10.2.3 Programm starten
Pfeil 10.2.4 Grafische Oberfläche aufbauen
Pfeil 10.2.5 Swing-Komponenten-Klassen
Pfeil 10.2.6 Funktionalität geben
Pfeil 10.3 Aller Swing-Anfang – Fenster zur Welt
Pfeil 10.3.1 Eine Uhr, bei der die Zeit nie vergeht
Pfeil 10.3.2 Swing-Fenster mit javax.swing.JFrame darstellen
Pfeil 10.3.3 Mit add(…) auf den Container
Pfeil 10.3.4 Fenster schließbar machen – setDefaultCloseOperation(int)
Pfeil 10.3.5 Sichtbarkeit des Fensters
Pfeil 10.3.6 Größe und Position des Fensters verändern
Pfeil 10.3.7 Fenster- und Dialogdekoration, Transparenz *
Pfeil 10.3.8 Die Klasse Toolkit *
Pfeil 10.3.9 Zum Vergleich: AWT-Fenster darstellen *
Pfeil 10.4 Beschriftungen (JLabel)
Pfeil 10.4.1 Mehrzeiliger Text, HTML in der Darstellung
Pfeil 10.5 Icon und ImageIcon für Bilder auf Swing-Komponenten
Pfeil 10.5.1 Die Klasse ImageIcon
Pfeil 10.6 Es tut sich was – Ereignisse beim AWT
Pfeil 10.6.1 Die Ereignisquellen und Horcher (Listener) von Swing
Pfeil 10.6.2 Listener implementieren
Pfeil 10.6.3 Listener bei dem Ereignisauslöser anmelden/abmelden
Pfeil 10.6.4 Adapterklassen nutzen
Pfeil 10.6.5 Innere Mitgliedsklassen und innere anonyme Klassen
Pfeil 10.6.6 Aufrufen der Listener im AWT-Event-Thread
Pfeil 10.6.7 Ereignisse, etwas genauer betrachtet *
Pfeil 10.7 Schaltflächen
Pfeil 10.7.1 Normale Schaltflächen (JButton)
Pfeil 10.7.2 Der aufmerksame ActionListener
Pfeil 10.7.3 Schaltflächen-Ereignisse vom Typ ActionEvent
Pfeil 10.7.4 Basisklasse AbstractButton
Pfeil 10.7.5 Wechselknopf (JToggleButton)
Pfeil 10.8 Textkomponenten
Pfeil 10.8.1 Text in einer Eingabezeile
Pfeil 10.8.2 Die Oberklasse der Textkomponenten (JTextComponent)
Pfeil 10.8.3 Geschützte Eingaben (JPasswordField)
Pfeil 10.8.4 Validierende Eingabefelder (JFormattedTextField)
Pfeil 10.8.5 Einfache mehrzeilige Textfelder (JTextArea)
Pfeil 10.8.6 Editor-Klasse (JEditorPane) *
Pfeil 10.9 Swing Action *
Pfeil 10.10 JComponent und Component als Basis aller Komponenten
Pfeil 10.10.1 Hinzufügen von Komponenten
Pfeil 10.10.2 Tooltips (Kurzhinweise)
Pfeil 10.10.3 Rahmen (Border) *
Pfeil 10.10.4 Fokus und Navigation *
Pfeil 10.10.5 Ereignisse jeder Komponente *
Pfeil 10.10.6 Die Größe und Position einer Komponente *
Pfeil 10.10.7 Komponenten-Ereignisse *
Pfeil 10.10.8 UI-Delegate – der wahre Zeichner *
Pfeil 10.10.9 Undurchsichtige (opake) Komponente *
Pfeil 10.10.10 Properties und Listener für Änderungen *
Pfeil 10.11 Container
Pfeil 10.11.1 Standardcontainer (JPanel)
Pfeil 10.11.2 Bereich mit automatischen Rollbalken (JScrollPane)
Pfeil 10.11.3 Reiter (JTabbedPane)
Pfeil 10.11.4 Teilungskomponente (JSplitPane)
Pfeil 10.12 Alles Auslegungssache – die Layoutmanager
Pfeil 10.12.1 Übersicht über Layoutmanager
Pfeil 10.12.2 Zuweisen eines Layoutmanagers
Pfeil 10.12.3 Im Fluss mit FlowLayout
Pfeil 10.12.4 BoxLayout
Pfeil 10.12.5 Mit BorderLayout in alle Himmelsrichtungen
Pfeil 10.12.6 Rasteranordnung mit GridLayout
Pfeil 10.12.7 Der GridBagLayoutmanager *
Pfeil 10.12.8 Null-Layout *
Pfeil 10.12.9 Weitere Layoutmanager
Pfeil 10.13 Rollbalken und Schieberegler
Pfeil 10.13.1 Schieberegler (JSlider)
Pfeil 10.13.2 Rollbalken (JScrollBar) *
Pfeil 10.14 Kontrollfelder, Optionsfelder, Kontrollfeldgruppen
Pfeil 10.14.1 Kontrollfelder (JCheckBox)
Pfeil 10.14.2 ItemSelectable, ItemListener und das ItemEvent
Pfeil 10.14.3 Sich gegenseitig ausschließende Optionen (JRadioButton)
Pfeil 10.15 Fortschritte bei Operationen überwachen *
Pfeil 10.15.1 Fortschrittsbalken (JProgressBar)
Pfeil 10.15.2 Dialog mit Fortschrittsanzeige (ProgressMonitor)
Pfeil 10.16 Menüs und Symbolleisten
Pfeil 10.16.1 Die Menüleisten und die Einträge
Pfeil 10.16.2 Menüeinträge definieren
Pfeil 10.16.3 Einträge durch Action-Objekte beschreiben
Pfeil 10.16.4 Mit der Tastatur – Mnemonics und Shortcut
Pfeil 10.16.5 Der Tastatur-Shortcut (Accelerator)
Pfeil 10.16.6 Tastenkürzel (Mnemonics)
Pfeil 10.16.7 Symbolleisten alias Toolbars
Pfeil 10.16.8 Popup-Menüs
Pfeil 10.16.9 System-Tray nutzen *
Pfeil 10.17 Das Model-View-Controller-Konzept
Pfeil 10.18 Auswahlmenüs, Listen und Spinner
Pfeil 10.18.1 Listen (JList)
Pfeil 10.18.2 Auswahlmenü (JComboBox)
Pfeil 10.18.3 Drehfeld (JSpinner) *
Pfeil 10.18.4 Datumsauswahl
Pfeil 10.19 Tabellen (JTable)
Pfeil 10.19.1 Ein eigenes Tabellen-Model
Pfeil 10.19.2 Basisklasse für eigene Modelle (AbstractTableModel)
Pfeil 10.19.3 Ein vorgefertigtes Standardmodell (DefaultTableModel)
Pfeil 10.19.4 Ein eigener Renderer für Tabellen
Pfeil 10.19.5 Zell-Editoren
Pfeil 10.19.6 Automatisches Sortieren und Filtern mit RowSorter *
Pfeil 10.20 Bäume (JTree)
Pfeil 10.20.1 JTree und sein TreeModel und TreeNode
Pfeil 10.20.2 Selektionen bemerken
Pfeil 10.20.3 Das TreeModel von JTree *
Pfeil 10.21 JRootPane und JDesktopPane *
Pfeil 10.21.1 Wurzelkomponente der Top-Level-Komponenten (JRootPane)
Pfeil 10.21.2 JDesktopPane und die Kinder von JInternalFrame
Pfeil 10.21.3 JLayeredPane
Pfeil 10.22 Dialoge und Window-Objekte
Pfeil 10.22.1 JWindow und JDialog
Pfeil 10.22.2 Modal oder nichtmodal?
Pfeil 10.22.3 Standarddialoge mit JOptionPane
Pfeil 10.22.4 Der Dateiauswahldialog
Pfeil 10.22.5 Der Farbauswahldialog JColorChooser *
Pfeil 10.23 Flexibles Java-Look-and-Feel
Pfeil 10.23.1 Look-and-Feel global setzen
Pfeil 10.23.2 UIManager
Pfeil 10.23.3 Die Windows-Optik mit JGoodies Looks verbessern *
Pfeil 10.24 Swing-Komponenten neu erstellen oder verändern *
Pfeil 10.24.1 Überlagerungen mit dem Swing-Komponenten-Dekorator JLayer
Pfeil 10.25 Die Zwischenablage (Clipboard)
Pfeil 10.25.1 Clipboard-Objekte
Pfeil 10.25.2 Mit Transferable auf den Inhalt zugreifen
Pfeil 10.25.3 DataFlavor ist das Format der Daten in der Zwischenablage
Pfeil 10.25.4 Einfügungen in der Zwischenablage erkennen
Pfeil 10.25.5 Drag & Drop
Pfeil 10.26 Undo durchführen *
Pfeil 10.27 AWT, Swing und die Threads
Pfeil 10.27.1 Ereignisschlange (EventQueue) und AWT-Event-Thread
Pfeil 10.27.2 Swing ist nicht threadsicher
Pfeil 10.27.3 invokeLater(…) und invokeAndWait(…)
Pfeil 10.27.4 SwingWorker
Pfeil 10.27.5 Eigene Ereignisse in die Queue setzen *
Pfeil 10.27.6 Auf alle Ereignisse hören *
Pfeil 10.28 Barrierefreiheit mit der Java Accessibility API
Pfeil 10.29 Zeitliches Ausführen mit dem javax.swing.Timer
Pfeil 10.30 Die Zusatzkomponentenbibliothek SwingX
Pfeil 10.30.1 Im Angebot: Erweiterte und neue Swing-Komponenten
Pfeil 10.30.2 Überblick über erweiterte Standard-Swing-Klassen
Pfeil 10.30.3 Neue Swing-Klassen
Pfeil 10.30.4 Weitere SwingX-Klassen
Pfeil 10.30.5 SwingX-Installation
Pfeil 10.31 Zum Weiterlesen
 
Zum Seitenanfang

10.6Es tut sich was – Ereignisse beim AWT Zur vorigen ÜberschriftZur nächsten Ü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.

 
Zum Seitenanfang

10.6.1Die Ereignisquellen und Horcher (Listener) von Swing Zur vorigen ÜberschriftZur nächsten Überschrift

Im Ereignismodell von Java gibt es Ereignisauslöser (Ereignisquellen, engl. event sources), wie zum Beispiel Schaltflächen oder Schieberegler. Die Ereignisse können vom Benutzer der grafischen Oberfläche kommen, etwa wenn er eine Schaltfläche anklickt, aber auch auf eigene Auslöser zurückzuführen sein, zum Beispiel wenn im Hintergrund eine Tabelle geladen wird.

Neben den Ereignisauslösern gibt es eine Reihe von Interessenten (Listener oder Horcher genannt), 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. Auf diese Weise leidet die Systemeffizienz nicht, da nur diejenigen informiert werden, die auch Verwendung für das Ereignis haben. Für jedes Ereignis gibt es einen eigenen Listener, an den das Ereignis weitergeleitet wird – darum der Name für das Modell: Delegation Model[ 96 ](Die Entwickler hatten vorher den Namen »Command Model« vergeben, doch drückte dies die Arbeitsweise nicht richtig aus.).

Tabelle 10.3 gibt eine Übersicht über einige Listener und zeigt, was für Ereignisse sie melden:

Listener

Ereignisse

ActionListener

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

WindowListener

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

MouseListener

Der Benutzer drückt auf eine Maustaste.

MouseMotionListener

Der Benutzer bewegt die Maus.

Tabelle 10.3Einige Listener und die von ihnen gemeldeten Ereignisse

Dem Listener übergibt das Swing-Grafiksystem jeweils ein Ereignis-Objekt, etwa 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.

Schritte zum richtigen Horchen

Damit die Quelle Ereignisse sendet und der Client darauf reagiert, sind zwei Schritte durchzuführen:

  1. Implementieren des Listeners

  2. Anmelden des Listeners

Um dieses Konzept kennenzulernen, wollen wir einen Fenster-Horcher programmieren, der registriert, ob ein Fenster geschlossen werden soll. Wenn ja, bietet er einen Dialog; bestätigt der Benutzer den Dialog, wird die Applikation beendet.

 
Zum Seitenanfang

10.6.2Listener implementieren Zur vorigen ÜberschriftZur nächsten Ü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.

Die Schnittstelle WindowListener

Alle Meldungen rund um Fenster werden über einen WindowListener abgewickelt. Implementierungen können so etwa erfahren, ob das Fenster vergrößert oder verkleinert wurde. Die Schnittstelle deklariert folgende Operationen:

interface java.awt.event.WindowListener
extends EventListener
  • void windowOpened(WindowEvent e)
    Wird aufgerufen, wenn das Fenster geöffnet wird.

  • 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.

UML-Diagramm von WindowListener und WindowEvent

Abbildung 10.21UML-Diagramm von WindowListener und WindowEvent

Der nächste Schritt ist, die Schnittstelle zu implementieren und in windowClosing(WindowEvent) Programmcode einzubetten, der den Benutzer fragt, ob die Anwendung wirklich geschlossen werden soll.

Wer implementiert die Schnittstelle WindowListener?

Bei der Implementierung der Schnittstelle WindowListener gibt es unterschiedliche Varianten:

  • Eine Klasse, die zum Beispiel JFrame erweitert, implementiert gleichzeitig WindowListener.

  • Eine externe Klasse implementiert die Listener-Schnittstelle.

  • Eine innere anonyme Klasse implementiert den Listener.

Die Lösungen haben Vor- und Nachteile. Wenn die eigene Klasse den Listener implementiert, ist das Programm schön kurz und der Listener hat einfachen Zugriff auf alle Zustände oder Variablen. Den Listener von einer anderen Klasse implementieren zu lassen hat dagegen den Vorteil, dass die Implementierung wiederverwendbar ist. Das ist bei einem allgemeinen Horcher für Fensterschließereignisse sicherlich angebracht.

Fensterschließ-Horcher

Die Implementierung fragt mit JOptionPane.showConfirmDialog(…), ob das Fenster wirklich geschlossen werden soll. Die nicht genutzten Callback-Methoden implementieren wir leer.

Listing 10.6com/tutego/insel/ui/event/DialogWindowClosingListener.java

package com.tutego.insel.ui.event;

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

public class DialogWindowClosingListener implements WindowListener {
@Override public void windowClosing( WindowEvent event ) {
int option = JOptionPane.showConfirmDialog( null, "Applikation beenden?" );
if ( option == JOptionPane.OK_OPTION )
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*/ }
}

An diesem Beispiel ist abzulesen, dass jeder, der ein WindowListener sein möchte, die vorgeschriebenen Methoden 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 und den Dialog mit OK bestätigt.

 
Zum Seitenanfang

10.6.3Listener bei dem Ereignisauslöser anmelden/abmelden Zur vorigen ÜberschriftZur nächsten Ü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 )

Üblicherweise lassen sich beliebig viele Listener an einen Ereignisauslöser hängen.

addXXXListener(…) nur dann möglich, wenn es auch Ereignisse gibt

Nicht jede Komponente kann jedes Ereignis auslösen. Daher gibt es nur addXXXListener(…) für Ereignisse, die die Komponenten tatsächlich auslösen, und unterschiedliche Komponenten bieten unterschiedliche Hinzufügen-Methoden. Die JFrame-Klasse bietet zum Beispiel addWindowListener(…) für Fensterereignisse, aber kein addActionListener(…) – das wiederum bietet JButton, damit er die Aktivierung der Schaltfläche melden kann. Eine Schaltfläche löst eben keine Fensterereignisse 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 Ereignistyp sein.

Fensterschließer registrieren

Den Listener für Fensterereignisse, unseren DialogWindowClosingListener, binden wir mit der Methode addWindowListener(…) an ein Fenster. Wird genau dieses Fenster geschlossen, bekommen wir das mit und können reagieren.

Listing 10.7com/tutego/insel/ui/event/CloseWithDialogFrame.java

package com.tutego.insel.ui.event;

import javax.swing.*;

public class CloseWithDialogFrame {
public static void main( String[] args ) {
JFrame f = new JFrame();
f.setDefaultCloseOperation( JFrame.DO_NOTHING_ON_CLOSE );
f.add( new JLabel( "Zyklone bringen Regen" ) );
f.pack();
f.addWindowListener( new DialogWindowClosingListener() );
f.setVisible( true );
}
}

Wir tragen mit addWindowListener(…) den Listener ein. Immer wenn ein Window-Event ausgelöst wird, kümmert sich die jeweilige Methode um dessen Abarbeitung.

Normalerweise schließt Swing einen JFrame automatisch, wenn das × gedrückt wird – anders als beim AWT-Frame. Die Anweisung setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE) verändert dieses Standardverhalten, damit nichts passiert und wir selbst zu 100  % die Kontrolle behalten. Denn ist die Zeile nicht im Programm, so merkt Swing, dass das × gedrückt wurde, und versteckt das Fenster, egal, was der Benutzer im Dialog angibt.

setDefaultCloseOperation(int) und der WindowListener *

Die ersten Swing-Programme, die wir geschrieben haben, nutzen setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE), damit Swing automatisch die Anwendung beendet, wenn der Anwender auf × klickt. Diese Belegung ist für kleine Testprogramme in Ordnung, in ausgewachsenen GUI-Anwendungen sollte sich die Applikation jedoch nicht einfach schließen, sondern mit einem Dialog über das Ende informieren. Die Voreinstellung für die Default-Close-Operation von JFrame ist HIDE_ON_CLOSE, was das Fenster automatisch verdeckt (das Fenster kann später wieder aktiviert werden), nachdem die WindowListener aufgerufen wurden. Eine weitere Konstante ist DISPOSE_ON_CLOSE, was ebenfalls die Listener abarbeitet, aber das Fenster automatisch schließt und alle Ressourcen freigibt. Übernehmen wir selbst die komplette Kontrolle, ist die Belegung mit JFrame.DO_NOTHING_ON_CLOSE angebracht.

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 sehen wir uns an, wie ein Programm beide Methoden nutzen oder meiden kann.

In den einfachen Programmen setzen wir in die windowClosing(…)-Methode einen Aufruf von System.exit(0), 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(0). Soll das Fenster jedoch mit × und dispose() einfach nur geschlossen werden oder ist eine gemeinsame Behandlung gewünscht, so ist es sinnvoll, in windowClosing(…) mit dispose() indirekt windowClosed(…) aufzurufen, etwa so:

@Override public void windowClosing( WindowEvent e ) {
e.getWindow().dispose();
}
@Override public void windowClosed( WindowEvent e ) {
// Das Fenster ist geschlossen, und jetzt können wir hier
// weitermachen, etwa mit System.exit(0), wenn alles
// vorbei sein soll.
}
 
Zum Seitenanfang

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

Hat eine Schnittstelle wie WindowListener viele Methoden, so hat eine Implementierung alle Methoden zu realisieren, auch wenn die Mehrzahl einen leeren Rumpf hat. Das ist lästig. 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 10.8java.awt.event.WindowAdapter.java

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.

UML-Diagramm von WindowAdapter

Abbildung 10.22UML-Diagramm von WindowAdapter

Wenn wir jetzt einen Ereignisbehandler implementieren müssen, erweitern wir einfach die Adapterklasse und überschreiben nur die relevanten Methoden. Der Listener zum Schließen des Fensters mit einer Adapterklasse sieht dann wie folgt aus:

Listing 10.9com/tutego/insel/ui/event/DialogWindowClosingListener2.java

package com.tutego.insel.ui.event;

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

public class DialogWindowClosingListener2 extends WindowAdapter {
@Override public void windowClosing( WindowEvent event ) {
int option = JOptionPane.showConfirmDialog( null, "Applikation beenden?" );
if ( option == JOptionPane.OK_OPTION )
System.exit( 0 );
}
}

Beim Client ändert sich nicht viel, es ist immer noch die addWindowListener(…)-Methode:

Listing 10.10com/tutego/insel/ui/event/CloseWithDialogFrame2.java, main()

JFrame f = new JFrame();
f.setDefaultCloseOperation( JFrame.DO_NOTHING_ON_CLOSE );
f.add( new JLabel( "Zyklone bringen Regen" ) );
f.pack();
f.addWindowListener( new DialogWindowClosingListener2() );
f.setVisible( true );
 
Zum Seitenanfang

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

Wir haben für das Fensterschließ-Beispiel eine externe Klasse benutzt, weil die Klasse für unterschiedliche Swing-Programme nützlich ist. Ist der Listener sehr individuell und mit der Komponente verbunden, so sind innere anonyme Klassen nützlich. Dazu zwei Beispiele.

Auf Klicks reagieren

Das JLabel kann Maus-Ereignisse empfangen, was wir nutzen wollen, um bei einem Doppelklick die Applikation zu beenden:

Listing 10.11com/tutego/insel/ui/event/ClickOnJLabelToClose.java, main()

JFrame frame = new JFrame();
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );

JLabel label = new JLabel( "Lebe immer First-Class, sonst tun es deine Erben!" );
label.setForeground( Color.BLUE );

frame.add( label );

label.addMouseListener( new MouseAdapter() {
@Override public void mouseClicked( MouseEvent e ) {
if ( e.getClickCount() > 1 )
System.exit( 0 );
}
} );

frame.pack();
frame.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 MouseAdapter ist nur hier sinnvoll und wird nur in diesem Kontext benötigt.

Dezimal-in-Hexadezimal-Umwandler

Innere Klassen sind elegant, denn sie können leicht auf Zustände der äußeren Klasse zugreifen. Das folgende Programm realisiert einen Hexadezimalwandler:

Listing 10.12com/tutego/insel/ui/event/HexConverter.java

package com.tutego.insel.ui.event;

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

public class HexConverter {
public static void main( String[] args ) {
JFrame frame = new JFrame();
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
frame.setLayout( new FlowLayout() );

final JTextField decTextField = new JTextField();
decTextField.setColumns( 5 );
frame.add( decTextField );
frame.add( new JLabel(" ist hexadezimal " ) );
final JTextField hexTextField = new JTextField();
hexTextField.setColumns( 5 );
frame.add( hexTextField );
JButton okButton = new JButton( "Konvertiere" );
frame.add( okButton );

okButton.addActionListener( new ActionListener() {
@Override public void actionPerformed( ActionEvent e ) {
int dec = Integer.parseInt( decTextField.getText() );
String hex = Integer.toHexString( dec );
hexTextField.setText( hex );
}
} );

frame.pack();
frame.setVisible( true );
}
}

Das Programm nutzt einige Dinge, die neu sind, aber gut verständlich: Damit mehrere Komponenten nebeneinandergesetzt werden, konfigurieren wir das Fenster mit einem FlowLayout. Dann platzieren wir ein Textfeld, eine Beschriftung, ein Textfeld und eine Schaltfläche nebeneinander. An die Schaltfläche kommt ein Listener, damit wir mitbekommen, ob sie bestätigt wurde. Wenn sie bestätigt wurde, erfolgt die Konvertierung (Fehler werden nicht abgefangen). Die anonyme Klasse kann dabei sehr gut auf die beiden Textfelder zurückgreifen. Wäre der Listener eine externe Klasse, so müssten ihr – etwa im Konstruktor – die beiden Textfelder mitgegeben werden.

 
Zum Seitenanfang

10.6.6Aufrufen der Listener im AWT-Event-Thread Zur vorigen ÜberschriftZur nächsten Ü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 laufen, 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 sie in eine Liste ein, sodass es dadurch eine Reihenfolge gibt, doch sollte diesem Implementierungsdetail keine Beachtung geschenkt werden.

 
Zum Seitenanfang

10.6.7Ereignisse, etwas genauer betrachtet * Zur vorigen ÜberschriftZur nächsten Überschrift

Die ausgesandten Botschaften werden in Ereignisklassen kategorisiert. Da es unterschiedliche Ereignisse (engl. events) gibt, kann das System somit die Ereignisse unterteilen und eine Vorauswahl treffen.

AWTEvent und Unterklassen 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-Ereignisklassen in dem Unterpaket java.awt.event befinden, liegt AWTEvent selbst direkt unter java.awt und damit nicht im Ereignis-Paket.

Eine wichtige Methode ist getID(). Jede Ereignisklasse definiert eine ID, durch die sich die Ereignisse neben ihrer Klassenzugehörigkeit unterscheiden. Für Ereignisse gedrückter Schaltflächen ist die ID etwa ActionEvent.ACTION_PERFORMED.

Die AWTEvent-Klasse und ihre Unterklassen

Abbildung 10.23Die AWTEvent-Klasse und ihre Unterklassen

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 30 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 einen Mausklick oder das Drücken der (¢)-Taste) oder ein Rollbalken bewegt wird (zum Beispiel durch die Maus oder durch die (Bild½)-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 nicht darauf 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 Tabelle 10.4:

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

Tabelle 10.4Ereignisklassen und ihre IDs

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.

Tabelle 10.5 zeigt für einige grafische Komponenten die Ereignisse und gibt an, wann sie ausgelöst werden können.

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

EyelidEvent

*) Nicht in der Java-API, aber in der Welt-API.

Tabelle 10.5Einige Ereignisauslöser

 


Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java SE 8 Standard-Bibliothek Java SE 8 Standard-Bibliothek
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: Java ist auch eine Insel
Java ist auch eine Insel


Zum Rheinwerk-Shop: Professionell entwickeln mit Java EE 8
Professionell entwickeln mit Java EE 8


Zum Rheinwerk-Shop: Besser coden
Besser coden


Zum Rheinwerk-Shop: Entwurfsmuster
Entwurfsmuster


Zum Rheinwerk-Shop: IT-Projektmanagement
IT-Projektmanagement


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2018. Original - https://www.rheinwerk-verlag.de/openbook/
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.

 

 
 


29.09.2022 - Sitemap.xml