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.25 AWT, Swing und die Threads ### 15.25.1 Ereignisschlange (EventQueue) und AWT-Event-Thread Der Benutzer erzeugt bei seiner Arbeit mit der Oberfläche Ereignisse. Diese werden entweder von den Peer-Objekten oder von Klassen der Applikation erzeugt. Bevor sie vom eigenen Programm bearbeitet werden, gelangen sie in eine Ereignisschlange (engl. event queue). Jedem Fenster ist eine eigene Event-Queue zugeordnet. Diese Event-Queue ist für Programmierer zugänglich und in einer plattformunabhängigen Klasse EventQueue implementiert. Elemente der Klasse sind Objekte vom Typ AWTEvent. Ein eigener Thread, der AWT-Event-Thread, läuft parallel zur Anwendung und arbeitet die angesammelten Ereignisse dieser Warteschlange ab. Der AWT-Thread führt auch den Programmcode in den Listenern aus. Aus diesem Grund ist es ungünstig, in einen Event-Handler lang dauernden Programmcode zu legen, denn dann »steht« die grafische Applikation und lässt sich nicht fortsetzen, weil der AWT-Thread blockiert ist. Bei einer längeren Aktion in einem Event-Handler sollten wir einen separaten Thread starten, damit die grafische Oberfläche sofort wieder reaktionsfähig ist.
Beispiel Wenn eine Schaltfläche angeklickt wird, soll ein langer Text in den Puffer eingelesen werden:
    ActionListener al = new ActionListener() {
      public void actionPerformed( ActionEvent e ) {
        new Thread( new ReaderThread(e.getActionCommand()) ).start();
      }
    };
In einer externen Klasse lesen wir zum Beispiel einen Text:
    class ReaderThread implements Runnable
    {
      ReaderThread( String actionCommand )
      {
        // ...
      }
      public void run() {
        // ...
      }
    }
Eine Alternative ist der Swing-Worker, der wir später vorstellen.
Unter dem AWT ist es kein Problem, wenn zwei Threads auf ein und dasselbe Oberflächen-element zugreifen. Bei Swing ist dies jedoch etwas anders, wie wir im nächsten Abschnitt sehen werden. ### 15.25.2 Swing ist nicht Thread-sicher Die Tatsache, dass das Swing-Toolkit nicht Thread-sicher ist, erstaunt vielleicht auf den ersten Blick. Das AWT ist Thread-sicher, da AWT auf Plattform-Peer-Elemente vertraut. In einer List-Box unter dem AWT ist es problemlos möglich, ein Element einzufügen und parallel zu löschen. Doch auf die Synchronisation bei Swing wurde aus zwei Gründen verzichtet: Operationen in Threads können zu ärgerlichen Deadlock-Situationen führen. Der Verzicht auf Synchronisation kann die Ausführungsgeschwindigkeit erhöhen.
Hinweis Gibt es konkurrierende Zugriffe auf Swing-Komponenten, kann es zu Exceptions der Art »Exception in thread "AWT-EventQueue-0" « kommen.
#### Erlaubte Methoden Einige der Methoden sind Thread-sicher und dürfen von beliebigen anderen Threads aufgerufen werden. Der Aufruf zum Neuzeichnen mit repaint() oder revalidate() für Größenänderung einer Komponente im Container. Bei neuen Komponenten, die noch nicht etwa mit setVisible() bearbeitet wurden. Die Eintragung von Listener, etwa bei JComponent mit den Funktionen addPropertyChangeListener(), removePropertyChangeListener() und addVetoableChangeListener(), removeVetoableChangeListener() ist sicher. Bei JCheckBoxMenuItem ist es dann die einsame Methode setState(boolean), die synchronisiert ist. Es findet sich intern mal hier mal da ein synchronisierter Block. Ansonsten ist jedoch nicht viel dabei, und wir müssen unsere Teile synchronisiert ausführen. Um Programmstücke konform ausführen zu lassen, definiert Swing einige Methoden und Klassen. Dazu gehören: invokeLater(Runnable) invokeAndWait(Runnable) JProgressBar ProgressMonitor ProgressMonitorInputStream SwingWorker ### 15.25.3 Swing-Elemente mit invokeLater() und invokeAndWait() bedienen Da Swing nicht Thread-sicher ist, bietet der AWT-Thread die einzige Möglichkeit zur Manipulation von Oberflächenelementen. Wenn wir es schaffen, dort die Aufträge einzureihen, dann wird nichts schief gehen. Genau für diese Aufgabe gibt es in der Klasse EventQueue zwei Methoden: invokeLater() und invokeAndWait(). Damit lassen sich beliebige Programmstücke in die Warteschlange einführen. In der Warteschlange für das AWT liegen Aufträge und Ereignisse, die an die Oberflächenelemente verteilt werden. Alles spielt sich dabei neben dem Haupt-Thread ab, so dass Parallelität herrscht. Hat die Warteschlange alle Ereignisbehandler aufgerufen, kann der Programmcode von invokeLater() und invokeAndWait() durchlaufen werden. Den Methoden wird ein Runnable-Objekt übergeben. Die beiden Methoden erfüllen unterschiedliche Bedürfnisse: invokeLater() legt einen Runnable in die Warteschlange und kehrt sofort zurück. Die Methode ist somit asynchron. Der Aufrufer weiß nicht, wann der Programmcode abgearbeitet wird. invokeAndWait() legt ebenfalls einen Runnable in die Warteschlange, verharrt aber so lange in der Methode, bis der Programmcode in run() aufgerufen wurde. Die Methode ist also synchron. Mit diesen Methoden lassen sich jetzt alle Manipulationen an der Oberfläche durchführen.
Beispiel Ein Fortschrittsbalken JProgressBar mit dem Namen bar soll aus einem Nicht-AWT-Event-Thread einen Wert gesetzt bekommen. EventQueue.invokeLater( new Runnable() { public void run() { bar.setValue( i ); } } );
Bei der Auswahl der beiden Funktionen haben wir uns für den Fortschrittsbalken für invokeLater() entschieden. Es ist in der Regel wenig sinnvoll, die Methode so lange stehen zu lassen, bis die Anzeige auch wirklich gezeichnet wurde. Ein Problem stellt für sehr viele Applikationen leider die Tatsache dar, dass das Objekt zur Manipulation immer irgendwie sichtbar sein muss. Hier soll bar einfach direkt für die innere Klasse sichtbar sein. Die Funktionen invokeLater() und invokeAndWait() befinden sich nicht nur in der Klasse EventQueue, sondern sind noch einmal in der Klasse SwingUtilities untergebracht. Daher ist es gleichgültig, ob wir EventQueue.invokeXXX() oder SwingUtilities.invokeXXX() schreiben. SwingUtilities hat vielleicht den Vorteil, dass das Paket java.awt für die EventQueue nicht importiert werden muss, sonst gibt es aber keinen Unterschied. #### Implementierung Genehmigen wir uns abschließend noch einen kurzen Blick auf die Implementierung. Es lässt sich schon erahnen, dass invokeLater() einfacher ist:
    public static void invokeLater( Runnable runnable )
    {
      Toolkit.getEventQueue().postEvent(
        new InvocationEvent(Toolkit.getDefaultToolkit(), runnable) );
    }
Das Ereignis, das in die Event-Queue kommt, ist vom Typ InvocationEvent und damit ein AWTEvent. Wir übergeben unser Runnable-Objekt, damit der AWT-Thread später die run()-Methode aufrufen kann. Die Methode invokeAndWait() ist etwas komplizierter; wir wollen von der Implementierung nur wenige Zeilen betrachten. Im Prinzip leistet die Methode das Gleiche wie invokeLater(); auch sie muss das InvocationEvent in die Warteschlange legen. Hinzu kommt jedoch, dass invokeAndWait() auf das Ende des Threads warten muss:
    InvocationEvent event = new InvocationEvent(
        Toolkit.getDefaultToolkit(), runnable, lock, true);
      synchronized (lock) {
        Toolkit.getEventQueue().postEvent(event);
        lock.wait();
    }
Das konstruierte InvocationEvent bekommt als Argument wieder das runnable. Jetzt erhält es aber zusätzlich ein Lock-Objekt. Wenn der AWT-Thread durch die Ereignis-Warteschlange geht und das InvocationEvent sieht, führt er wieder die run()-Methode aus. Anschließend informiert er über notify() das wartende Objekt. Dann steigt invokeAndWait() aus dem synchronized-Block aus, und es geht weiter. ### 15.25.4 SwingWorker Mit dem SwingWorker aus Java 6 (für frühere Java-Versionen liegt eine Version mit Dokumentation unter https://swingworker.dev.java.net/ vor) ist es einfach möglich, längere Programmteile im Hintergrund von einem Nicht-AWT-Thread abarbeiten zu lassen und dann später die Ergebnisse über den AWT-Thread wieder in die GUI einfließen zu lassen. Für einen eigenen SwingWorker ist zunächst eine Unterklasse von javax.swing.SwingWorker zu bilden. Wir wollen eine Klasse ClockPrecision angeben, die zwei Sekunden wartet und dabei die Zeit misst – das Ergebnis ist durch Ungenauigkeit nicht wirklich 2 Sekunden. Wir interessieren uns hier für die Ungenauigkeit. Nach Ablauf der Zeit soll der SwingWorker das Ergebnis auf die Schaltfläche schreiben, die auch der Auslöser für die Warterei ist. Listing 15.74 com/tutego/insel/ui/event/SwingWorkerDemo.java
    package com.tutego.insel.ui.event;

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

    public class SwingWorkerDemo extends JFrame
    {
      JButton button = new JButton( "Change my mind!" );

      SwingWorkerDemo()
      {
        setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
        add( button );

        ActionListener al = new ActionListener() {
          public void actionPerformed( ActionEvent e )
          {
            new ClockPrecision().execute();
          }
        };

        button.addActionListener( al );

        pack();
      }

      class ClockPrecision extends SwingWorker<Long, Object>
      {
        @Override public Long doInBackground()
        {
          long startNano = System.nanoTime();
          try { Thread.sleep( 2000 ); } catch ( InterruptedException e ) { }
          return (System.nanoTime() – startNano ) / (1000*1000);
        }

        @Override protected void done()
        {
          try
          {
            button.setText( "" + get() );
          }
          catch ( /* InterruptedException, ExecutionException */ Exception e ) { }
        }
      }

      public static void main( String[] args )
      {
        new SwingWorkerDemo().setVisible( true );
      }
    }
Die Methode done() bekommt die Rückgabe von doInBackground() über die get()-Methode. Unser SwingWorker durchläuft mehrere Phasen, an denen wir uns durch Überschreiben einiger Methoden aktiv beteiligen: Es beginnt mit execute(), was den SwingWorker dazu bewegt, einen so genannten Worker-Thread aufzubauen. Der Worker-Thread ruft doInBackground() auf, in dem wir unseren im Hintergrund auszuführenden Programmteil setzen. Der Rückgabetyp ist durch die generische Verwendung frei wählbar. Da SwingWorker auch vom Typ Future ist, kann das Ergebnis einer Berechnung get() liefern. Sind mit addPropertyChangeListener() neue PropertyChangeListener angemeldet, können wir sie mit firePropertyChange() aufrufen und während der Verarbeitung Status-Ereignisse schicken. Es erlaubt publish() das Absenden von Zwischenergebnissen, die sich unter dem AWT-Event in process() verarbeiten lassen. Dieser Typ kann ein anderer als der von get() sein, und so bestimmt die zweite Typvariable der generischen Klasse diesen Typ. Am Ende des Worker-Threads kommt es im AWT-Event-Thread zu einem Aufruf von done(), wo wir unsere Swing-Operationen vornehmen können. Der API-Dokumentation ist Weiteres zu entnehmen. ### 15.25.5 Eigene Ereignisse in die Queue setzen Es ist ohne großen Umweg möglich, eigene Ereignisse zu erzeugen und in der EventQueue zu platzieren. Damit lassen sich beispielsweise Eingaben des Benutzers emulieren. Da alle Ereignisse von Komponenten von AWTEvent erben, lässt sich ein ActionEvent erzeugen, das dann wiederum von einem interessierten Listener entgegengenommen wird. Jetzt fehlt uns nur noch eine Funktion, die Ereignisse in die Schlange setzt. Dazu bietet die Klasse EventQueue die Methode postEvent(). Im Beispiel sehen wir die notwendigen Aufrufe, um beginnend vom Toolkit an die SystemEventQueue zu kommen:
    Toolkit.getDefaultToolkit().getSystemEventQueue().
      postEvent(
       new ActionEvent( /* Object source, int id, String command */ )
      );
    class java.awt.Toolkit
final EventQueue getSystemEventQueue() Liefert ein Exemplar der EventQueue für eine Applikation oder ein Applet. Eine Security Exception wird ausgelöst, falls der Security-Manager den Zugriff auf EventQueue verbietet.
    class java.awt.EventQueue
void postEvent( AWTEvent theEvent ) Legt ein Ereignis in die EventQueue. Danach werden vorhandene EventQueueListener und notifyEventQueueListener aufgerufen. #### Einer Komponent ein Ereignis schicken Ist die Komponente bekannt, der ein Ereignis geschickt werden soll, lässt sich die Component-Funktion dispatchEvent(AWTEvent e) verwenden. Sie sendet ein AWTEvent – die Basisklasse aller AWT-Ereignisse – an die Komponente, womit alle Listener aufgerufen werden. Für die Schaltfläche b:
    b.dispatchEvent( new ActionEvent(b,ActionEvent.ACTION_PERFORMED, "text") );
### 15.25.6 Auf alle Ereignisse hören Um keine Ereignisse zu versäumen, lässt sich über das Toolkit ein Super-Listener anmelden. Dieser Listener ist vom Typ AWTEventListener, der über addAWTEventListener() mit dem Toolkit verbunden wird:
    AWTEventListener ael = new AWTEventListener() {
      public void eventDispatched( AWTEvent event ) {
      }
    };
    Toolkit.getDefaultToolkit().addAWTEventListener( ael, mask );
Die mask bestimmt den Typ der gemeldeten AWTEvents. Hier kann für Mausbewegungen etwa AWTEvent.MOUSE_MOTION_EVENT_MASK stehen. ### 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