Funktionsweise von Eventhandlern

[Turing0001]

Hallo ihr Java Fans,

vor einigen Tagen schoss mir ein Geadnke durch den Kopf, der mich seither nicht mehr loslässt und für das damit verbunbdene Problem konnte ich noch keine befriedigende Lösung finden: Man benutzt wie selbstverständlich die Eventhandler ( ActionListener, WindowListener etc.), aber was mir nicht klar ist: Wo ist hinterlegt, welche Funktion des jeweiligen Interfaces bei welchem Ereignis aufgerufen wird? Wer ruft (automatisch) die WindowClosing()-Funktion auf, wenn ich etwa ein AWT-Frame durch Klick in der rechten oberen Ecke das Fenster schließe. Verzeiht, wenn die Frage dumm sein sollte, vielleicht sehe ich auch nur den Wald vor lauter Bäumen nicht. Vielen Dank jedenfalls vorab für eure Mühe.

 

[LimDul]

So dumm ist die Frage nicht. Es gibt in Swing den sogenannten EDT - Event Dispatching Thread. Der ist für genau diese gesamte Logik im Großen und ganzen Zuständig. Der besteht im Prinzip - sinnbildlich - aus einer Endlosschleife und macht nichts anderes als nachzuschauen, wo ist was passiert und wer muss darauf hören.

Beispiel für das X. Wenn du darauf klickst, wird das irgendwo gespeichert. Jetzt kommt der EDT in seiner Endlosschleife vorbei und sieht "Bei dem Frame X wurde das Ereignis "Window Closed" ausgelöst. Also nimmt der der EDT das Event und schaut nach, wer alles als Listener eingetragen ist und ruft die dann nacheinander auf.

 

[Neumi5694]

Wenn du mal so einen Event schreibst, kannst du dir an der Stelle mal den Stacktrace ausgeben lassen (new Throwable().getStackTrace()).
Den Fenster-spezifischen Code wirst du in der Window-Klasse finden (sofern du mit Swing oder AWT arbeitest), das Auslösen selbst wird aber in Klassen des java.desktop Package erledigt.

 

[httpdigest]

Wer ruft (automatisch) die WindowClosing()-Funktion auf, wenn ich etwa ein AWT-Frame durch Klick in der rechten oberen Ecke das Fenster schließe.

Beim Klick auf den Schliessen-Knopf eines AWT Frame generiert zuerst einmal dein Mausklick das eigentliche Ereignis. Das heisst, dein Mausklick führt zu einem USB Human Interface Device Event, welches vom Kernel/Treiber des Betriebssystems entgegen genommen wird. Das Betriebssystem bzw. der Windowmanager schaut dann nach, zu welcher Anwendung der Klick gehört, also wo der Mauszeiger letztlich war, als der Klick auslöste. Für den ganz konkreten Fall, dass du auf das X des Fensters (welches für das Betriebssystem bzw. den WindowManager ein ganz normales natives Fenster ist und erstmal nichts mit Java zu tun hat) klickst, generiert das Betriebssystem (unter Windows) ein WM_CLOSE Ereignis und sendet es an die Window-Message-Queue des Java Prozesses, weil das Fenster/Frame diesem Prozess gehört. AWT selbst hat bei der ersten Verwendung einer AWT-Klasse (wie etwa einem Frame) im Hintergrund einen EventDispatcher Thread gestartet, der genau diese Window Message Queue periodisch polled (bzw. auf Ereignisse blockierend wartet). Kommt ein solches Ereignis, wie eben das WM_CLOSE Ereignis, dann interpretiert ein letztlich grosses switch-case Statement in AWT (ausgeführt vom EventDispatcher Thread) dieses Ereignis und schaut nach, welchem AWT Window das im Event übergebene WindowHandle gehört. Die Kombination WindowHandle + dass es sich um ein Fenster-Schliessen-Ereignis handelt, sorgt dann dafür, dass der entsprechende Callback/EventHandler am AWT Frame durch den EventDispatcher Thread aufgerufen wird.

 

[Turing0001]

Beim Klick auf den Schliessen-Knopf eines AWT Frame generiert zuerst einmal dein Mausklick das eigentliche Ereignis. Das heisst, dein Mausklick führt zu einem USB Human Interface Device Event, welches vom Kernel/Treiber des Betriebssystems entgegen genommen wird. Das Betriebssystem bzw. der Windowmanager schaut dann nach, zu welcher Anwendung der Klick gehört, also wo der Mauszeiger letztlich war, als der Klick auslöste. Für den ganz konkreten Fall, dass du auf das X des Fensters (welches für das Betriebssystem bzw. den WindowManager ein ganz normales natives Fenster ist und erstmal nichts mit Java zu tun hat) klickst, generiert das Betriebssystem (unter Windows) ein WM_CLOSE Ereignis und sendet es an die Window-Message-Queue des Java Prozesses, weil das Fenster/Frame diesem Prozess gehört. AWT selbst hat bei der ersten Verwendung einer AWT-Klasse (wie etwa einem Frame) im Hintergrund einen EventDispatcher Thread gestartet, der genau diese Window Message Queue periodisch polled (bzw. auf Ereignisse blockierend wartet). Kommt ein solches Ereignis, wie eben das WM_CLOSE Ereignis, dann interpretiert ein letztlich grosses switch-case Statement in AWT (ausgeführt vom EventDispatcher Thread) dieses Ereignis und schaut nach, welchem AWT Window das im Event übergebene WindowHandle gehört. Die Kombination WindowHandle + dass es sich um ein Fenster-Schliessen-Ereignis handelt, sorgt dann dafür, dass der entsprechende Callback/EventHandler am AWT Frame durch den EventDispatcher Thread aufgerufen wird.

Hallo,

vielen Dank euch allen, das hat mir sehr geholfen. Dass es mit dem EDT zusammenhängt hatte ich schon vermutet. Besonderen Dank an httpdigest für die tiefere Einsicht!

 

[Mart]

In javafx wird es Event dispatch Chain genannt und nicht Event dispatch Thread ob es unterschiede gibt ausserhalb der namen weis ich nicht

 

[kneitzel]

In javafx wird es Event dispatch Chain genannt und nicht Event dispatch Thread ob es unterschiede gibt ausserhalb der namen weis ich nicht

Nein, da verwechselst Du etwas. Natürlich gibt es auch in JavaFX einen Thread, der die Events verarbeitet. Dieser wird JavaFX Application Thread genannt.

EventDispatcher sind Verarbeiter von einem Event. Ein Event wird von einem EventDispatcherChain verarbeitet.

Wie das mit dem Verarbeiten von Events abläuft mit dem EventDispatchChain und was bei eigenen EventDispatchern zu beachten ist, findet sich in Ansätzen z.B. hier:

EventDispatcher (JavaFX 8)

Aber die Frage ist, ob und wann man so tief da eintauchen will....