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 Mathematisches
6 Eigene Klassen schreiben
7 Angewandte Objektorientierung
8 Exceptions
9 Die Funktionsbibliothek
10 Threads und nebenläufige Programmierung
11 Raum und Zeit
12 Datenstrukturen und Algorithmen
13 Dateien und Datenströme
14 Die eXtensible Markup Language (XML)
15 Grafische Oberflächen mit Swing
16 Grafikprogrammierung
17 Netzwerkprogrammierung
18 Verteilte Programmierung mit RMI und Web-Services
19 JavaServer Pages und Servlets
20 Applets
21 Midlets und die Java ME
22 Datenbankmanagement mit JDBC
23 Reflection und Annotationen
24 Logging und Monitoring
25 Sicherheitskonzepte
26 Java Native Interface (JNI)
27 Dienstprogramme für die Java-Umgebung
A Die Begleit-DVD
Stichwort
Download: - ZIP, ca. 12,5 MB
Buch bestellen
Ihre Meinung?
<< zurück | Galileo Computing / <openbook> /Java-Insel | vor >>
Java ist auch eine Insel von Christian Ullenboom Programmieren mit der Java Standard Edition Version 6
Java ist auch eine Insel 7., aktualisierte Auflage geb., mit DVD (November 2007) 1.492 S., 49,90 Euro Galileo Computing ISBN 978-3-8362-1146-8 |
| 15 Grafische Oberflächen mit Swing
|  | 15.1 Das Abstract Window Toolkit und Swing
|  |  | 15.1.1 Abstract Window Toolkit (AWT)
|  |  | 15.1.2 Java Foundation Classes
|  |  | 15.1.3 Was Swing von AWT unterscheidet
|  |  | 15.1.4 Die Klasse Toolkit
|  | 15.2 Fenster unter grafischen Oberflächen
|  |  | 15.2.1 Swing-Fenster darstellen
|  |  | 15.2.2 AWT-Fenster darstellen
|  |  | 15.2.3 Sichtbarkeit des Fensters
|  |  | 15.2.4 Größe und Position des Fensters verändern
|  |  | 15.2.5 Unterklassen der Fenster-Klassen bilden
|  |  | 15.2.6 Fenster- und Dialog-Dekoration
|  |  | 15.2.7 Dynamisches Layout während einer Größenänderung
|  | 15.3 Beschriftungen (JLabel)
|  |  | 15.3.1 Mehrzeiliger Text, HTML in der Darstellung
|  | 15.4 Icon und ImageIcon für Bilder auf Swing-Komponenten
|  |  | 15.4.1 Die Schnittstelle Icon
|  | 15.5 Es tut sich was – Ereignisse beim AWT
|  |  | 15.5.1 Die Klasse AWTEvent
|  |  | 15.5.2 Events auf verschiedenen Ebenen
|  |  | 15.5.3 Swings Ereignisquellen und Horcher (Listener)
|  |  | 15.5.4 Listener implementieren
|  |  | 15.5.5 Listener bei dem Ereignisauslöser anmelden/abmelden
|  |  | 15.5.6 Aufrufen der Listener im AWT-Event-Thread
|  |  | 15.5.7 Adapterklassen nutzen
|  |  | 15.5.8 Innere Mitgliedsklassen und innere anonyme Klassen
|  | 15.6 Schaltflächen
|  |  | 15.6.1 Normale Schaltflächen (JButton)
|  |  | 15.6.2 Der aufmerksame ActionListener
|  |  | 15.6.3 Basisklasse AbstractButton
|  |  | 15.6.4 Wechselknopf (JToggleButton)
|  | 15.7 Swing Action
|  |  | 15.7.1 javax.swing.Action
|  |  | 15.7.2 Eigenschaften der Action-Objekte
|  | 15.8 JComponent und Component als Basis aller Komponenten
|  |  | 15.8.1 Tooltips
|  |  | 15.8.2 Rahmen (Border)
|  |  | 15.8.3 Fokus und Navigation
|  |  | 15.8.4 Ereignisse jeder Komponente
|  |  | 15.8.5 Die Größe und Position einer Komponente
|  |  | 15.8.6 Komponenten-Ereignisse
|  |  | 15.8.7 Hinzufügen von Komponenten
|  |  | 15.8.8 UI-Delegate – der wahre Zeichner
|  |  | 15.8.9 Undurchsichtige (opak) Komponente
|  |  | 15.8.10 Properties und Listener für Änderungen
|  |  | 15.8.11 Swing-Beschriftungen eine andere Sprache geben
|  | 15.9 Container
|  |  | 15.9.1 Standardcontainer (JPanel)
|  |  | 15.9.2 Bereich mit automatischen Rollbalken (JScrollPane)
|  |  | 15.9.3 Reiter (JTabbedPane)
|  |  | 15.9.4 Teilung-Komponente (JSplitPane)
|  | 15.10 Alles Auslegungssache: die Layoutmanager
|  |  | 15.10.1 Übersicht über Layoutmanager
|  |  | 15.10.2 Zuweisen eines Layoutmanagers
|  |  | 15.10.3 Im Fluss mit FlowLayout
|  |  | 15.10.4 Mit BorderLayout in allen Himmelsrichtungen
|  |  | 15.10.5 Rasteranordnung mit GridLayout
|  |  | 15.10.6 Der GridBagLayout-Manager
|  |  | 15.10.7 Null-Layout
|  |  | 15.10.8 BoxLayout
|  |  | 15.10.9 Weitere Layoutmanager
|  | 15.11 Rollbalken und Schieberegler
|  |  | 15.11.1 Schieberegler (JSlider)
|  |  | 15.11.2 Rollbalken (JScrollBar)
|  | 15.12 Kontrollfelder, Optionsfelder, Kontrollfeldgruppen
|  |  | 15.12.1 Kontrollfelder (JCheckBox)
|  |  | 15.12.2 ItemSelectable, ItemListener und das ItemEvent
|  |  | 15.12.3 Sich gegenseitig ausschließende Optionen (JRadioButton)
|  | 15.13 Fortschritte bei Operationen überwachen
|  |  | 15.13.1 Fortschrittsbalken (JProgressBar)
|  |  | 15.13.2 Dialog mit Fortschrittsanzeige (ProgressMonitor)
|  | 15.14 Menüs und Symbolleisten
|  |  | 15.14.1 Die Menüleisten und die Einträge
|  |  | 15.14.2 Menüeinträge definieren
|  |  | 15.14.3 Einträge durch Action-Objekte beschreiben
|  |  | 15.14.4 Mit der Tastatur: Mnemonics und Shortcut
|  |  | 15.14.5 Der Tastatur-Shortcut (Accelerator)
|  |  | 15.14.6 Tastenkürzel (Mnemonics)
|  |  | 15.14.7 Symbolleisten alias Toolbars
|  |  | 15.14.8 Popup-Menüs
|  |  | 15.14.9 System-Tray nutzen
|  | 15.15 Das Model-View-Controller-Konzept
|  | 15.16 Auswahlmenüs, Listen und Spinner
|  |  | 15.16.1 Auswahlmenü (JComboBox)
|  |  | 15.16.2 Zuordnung einer Taste mit einem Eintrag
|  |  | 15.16.3 Datumsauswahl
|  |  | 15.16.4 Listen (JList)
|  |  | 15.16.5 Drehfeld (JSpinner)
|  | 15.17 Texteingabefelder
|  |  | 15.17.1 Text in einer Eingabezeile
|  |  | 15.17.2 Die Oberklasse der Text-Komponenten (JTextComponent)
|  |  | 15.17.3 Geschützte Eingaben (JPasswordField)
|  |  | 15.17.4 Validierende Eingabefelder (JFormattedTextField)
|  |  | 15.17.5 Einfache mehrzeilige Textfelder (JTextArea)
|  |  | 15.17.6 Editor-Klasse (JEditorPane)
|  | 15.18 Tabellen (JTable)
|  |  | 15.18.1 Ein eigenes Tabellen-Model
|  |  | 15.18.2 Basisklasse für eigene Modelle (AbstractTableModel)
|  |  | 15.18.3 Vorgefertigtes Standard-Modell (DefaultTableModel)
|  |  | 15.18.4 Ein eigener Renderer für Tabellen
|  |  | 15.18.5 Zell-Editoren
|  |  | 15.18.6 Größe und Umrandung der Zellen
|  |  | 15.18.7 Spalteninformationen
|  |  | 15.18.8 Tabellenkopf von Swing-Tabellen
|  |  | 15.18.9 Selektionen einer Tabelle
|  |  | 15.18.10 Automatisches Sortieren und Filtern mit RowSorter
|  |  | 15.18.11 Ein professionelles Tabellenlayout mit JGrid
|  | 15.19 Bäume (JTree)
|  |  | 15.19.1 JTree und sein TreeModel und TreeNode
|  |  | 15.19.2 Selektionen bemerken
|  |  | 15.19.3 Das TreeModel von JTree
|  | 15.20 JRootPane, JLayeredPane und JDesktopPane
|  |  | 15.20.1 Wurzelkomponente der Top-Level-Komponenten (JRootPane)
|  |  | 15.20.2 JLayeredPane
|  |  | 15.20.3 JDesktopPane und die Kinder JInternalFrame
|  | 15.21 Dialoge und Window-Objekte
|  |  | 15.21.1 JWindow und JDialog
|  |  | 15.21.2 Modal oder nicht-modal
|  |  | 15.21.3 Standarddialoge mit JOptionPane
|  |  | 15.21.4 Der Farbauswahldialog JColorChooser
|  |  | 15.21.5 Der Dateiauswahldialog
|  | 15.22 Flexibles Java-Look
|  |  | 15.22.1 L & F global setzen
|  |  | 15.22.2 UIManager
|  |  | 15.22.3 Verbessern des Aussehens unter Windows mit JGoodies Looks
|  | 15.23 Die Zwischenablage (Clipboard)
|  |  | 15.23.1 Clipboard-Objekte
|  |  | 15.23.2 Auf den Inhalt zugreifen mit Transferable
|  |  | 15.23.3 DataFlavor ist das Format der Daten in der Zwischenablage
|  |  | 15.23.4 Einfügungen in der Zwischenablage erkennen
|  |  | 15.23.5 Drag
|  | 15.24 Undo durchführen
|  | 15.25 AWT, Swing und die Threads
|  |  | 15.25.1 Ereignisschlange (EventQueue) und AWT-Event-Thread
|  |  | 15.25.2 Swing ist nicht Thread-sicher
|  |  | 15.25.3 Swing-Elemente mit invokeLater() und invokeAndWait() bedienen
|  |  | 15.25.4 SwingWorker
|  |  | 15.25.5 Eigene Ereignisse in die Queue setzen
|  |  | 15.25.6 Auf alle Ereignisse hören
|  | 15.26 Barrierefreiheit mit der Java Accessibility API
|  | 15.27 Benutzerinteraktionen automatisieren
|  |  | 15.27.1 Automatisch in die Tasten hauen
|  |  | 15.27.2 Mausoperationen
|  |  | 15.27.3 Methoden zur Zeitsteuerung
|  |  | 15.27.4 Screenshots
|  |  | 15.27.5 MouseInfo und PointerInfo
|  | 15.28 Zeitliches Ausführen mit dem javax.swing.Timer
|  | 15.29 Alternativen zu AWT und Swing
|  |  | 15.29.1 XML-Beschreibungen der Oberfläche: Swixml, XUL/Luxor
|  |  | 15.29.2 SWT (Standard Widget Toolkit)
|  | 15.30 Zum Weiterlesen
## 15.5 Es tut sich was – Ereignisse beim AWT 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. ### 15.5.1 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 AWT-Event 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. #### 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 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 Win-dowEvent, 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.5.2 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-Tasten) oder ein Rollbalken bewegt wird (zum Beispiel durch die Maus oder durch die Page-Up-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 15.1 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 niedrige Ereignisse lösen Fenster und Dialoge aus; sie senden Objekte 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. [Frauen zwinkern doppelt so häufig wie Männer. ]
Tabelle 15.2 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 | EyelidEvent
### 15.5.3 Swings Ereignisquellen und Horcher (Listener) 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 – von daher 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.
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.
MouseListene r | 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. Der Einzige, der etwas aus der Reihe tanzt, ist der MouseListener und MouseMotionListener, denn beide melden MouseEvent-Objekte. ### 15.5.4 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, kann die Ereignisquelle davon ausgehen, dass der Horcher die entsprechende Methode besitzt. Diese ruft die Quelle 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. Hier klicken, um das Bild zu vergrößern Listing 15.7 com/tutego/insel/ui/event/CloseWindowImplementsAll.java
    package com.tutego.insel.ui.event;

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

    class CloseWindowImplementsAll extends JFrame implements WindowListener
    {
      // Implementiere WindowListener

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

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

      //

      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 Funktionen nicht implementiert, da sie uns nicht interessieren. Die Implementierung ist so, dass die Anwendung beendet wird, wenn der Anwender auf das X 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. ### 15.5.5 Listener bei dem Ereignisauslöser anmelden/abmelden 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. add Ereignis Listener( Ereignis Listener ) remove Ereignis Listener( Ereignis Listener ) Dies bedeutet, dass etwa ein Listener für Fenster-Ereignisse, ein WindowListener, der Window Event-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 15.8 CloseWindowImplementsAll.java, CloseWindowImplementsAll()
      CloseWindowImplementsAll()
      {
        setSize( 400, 400 );
        addWindowListener( this );
        setVisible( true );
      }
addWindowListener() trägt den Listener (sich selbst) in eine interne Liste ein. Immer wenn ein Event ausgelöst wird, kümmert sich die jeweilige Funktion 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. ### 15.5.6 Aufrufen der Listener im AWT-Event-Thread 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 sie Sun in ihrer Implementierung in eine Liste ein, sodass es dadurch eine Reihenfolge gibt, doch sollte es keine Beachtung dieses Implementierungsdetails geben. ### 15.5.7 Adapterklassen nutzen Der Nachteil der ersten Variante besteht darin, 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.9 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 15.10 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); }
    }
Hier klicken, um das Bild zu vergrößern #### 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 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 window-Closed() 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 und das Fenster geschlossen werden soll. HIDE_ON_CLOSE ist die Standardeinstellung. ### 15.5.8 Innere Mitgliedsklassen und innere anonyme Klassen 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()-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. Implementieren wir unser Programm zum Schließen des Fensters mit einer inneren anonymen Klasse: Listing 15.11 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. ### Ihr Kommentar Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
Name |
E-Mail |
Ihr Kommentar |
<< zurück | <top> | vor >>

Copyright © Galileo Press 2008
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.

[Galileo Computing]
Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de