awt und multithreading

interpreter

Jeder Frame startet beim Anzeigen (durch setVisible(true) oder show()) seinen eigenen Thread für die Events. Der Thread für deinen JFrame läuft so lange, bis du das Fenster schließt und da das ja kein Demon-Thread ist läuft solange auch dein Programm weiter.

Also das setVisible startet eine Messageloop? Geil, dass das in der Doku steht.

Das macht jetzt aber nur dieses JFrame, oder machen des die ganzen Buttons und so auch?

interpreter

Optimizer schrieb:

Also das setVisible startet eine Messageloop?

Ja

Das macht jetzt aber nur dieses JFrame, oder machen des die ganzen Buttons und so auch?

setVisible ist eine Methode von JComponent, also machen das wohl alle Subklassen von JComponent so. Warum sollte man auch ein Eventhandling für eine Komponente starten, wenn sie nicht sichtbar ist?

Ich verstehe langsam den Zusammenhang. Es gibt anscheinend einen Event-Thread und alle sichtbaren Komponenten halten ihn am Leben.
Hmmmm aber setVisible(false) killt ihn andererseits auch nicht. Komisches System. Das Tutorial von Sun suckt auch irgendwie.

net 0

Optimizer schrieb:

Ich verstehe langsam den Zusammenhang. Es gibt anscheinend einen Event-Thread und alle sichtbaren Komponenten halten ihn am Leben.
Hmmmm aber setVisible(false) killt ihn andererseits auch nicht.

gekillt wird der, wenn vom letzten fenster die 'dispose()'-methode aufgerufen wird. ich glaube auch nicht, dass 'setVisible' irgendeinen einfluss darauf hat. dieser event-dispatcher thread beginnt zu laufen, wenn die erste instanz von 'java.awt.window' bzw. eines abkömmlings erzeugt wird.

Ne, sieht nicht so aus. Wenn ich das Fenster nicht sichtbar mach, wird das Programm sofort wieder beendet.
Das mit dem dispose() scheint zu stimmen.

interpreter

net schrieb:

Optimizer schrieb:

Ich verstehe langsam den Zusammenhang. Es gibt anscheinend einen Event-Thread und alle sichtbaren Komponenten halten ihn am Leben.
Hmmmm aber setVisible(false) killt ihn andererseits auch nicht.

gekillt wird der, wenn vom letzten fenster die 'dispose()'-methode aufgerufen wird. ich glaube auch nicht, dass 'setVisible' irgendeinen einfluss darauf hat. dieser event-dispatcher thread beginnt zu laufen, wenn die erste instanz von 'java.awt.window' bzw. eines abkömmlings erzeugt wird.

Nein.

Ok, also ist das jetzt so korrekt, dass der Event Thread startet, sobald das erste Control sichtbar ist und endet, sobald das letzte Control disposed ist?

Wieso steht das nicht in der Doku oder im Sun-Tutorial? Ich finde das nicht unwichtig, zu wissen, was für Threads wie lange laufen.

interpreter

Ich habe mich nie sooo genau damit beschäftigt, wann nun wo irgendwelche Threads starten (braucht man eigentlich auch nicht). Wenn erforderlich, dann startet eben der AWT Thread und anscheinend gibt es immer nur einen Thread für alle Events:

Swing event-handling and painting code executes in a single thread, called the event-dispatching thread

http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html
(Dies allerdings nur die logische Betrachtung. Effektiv kann der AWT-Event-Thread aus mehreren Threads bestehen).
Mit SwingUtilities kann man selber Aktionen in diese Event-Queue einreihen.

Wann dieser Thread genau endet kann ich dir nicht sagen. Vermutlich wenn er eben nicht mehr benötigt wird und das wäre dann, wenn keine Komponente mehr sichtbar ist.

net 0

interpreter schrieb:

net schrieb:

Optimizer schrieb:

Ich verstehe langsam den Zusammenhang....

gekillt wird der, wenn vom letzten fenster die 'dispose()'-methode aufgerufen wird. ich glaube auch nicht, dass 'setVisible' irgendeinen einfluss darauf hat. dieser event-dispatcher thread beginnt zu laufen, wenn die erste instanz von 'java.awt.window' bzw. eines abkömmlings erzeugt wird.

Nein.

wie nein?
das mit dem 'dispose' oder das mit dem starten des threads?
mein aussage bezog sich übrigens auf normales awt, also ohne swing

interpreter schrieb:

Mit SwingUtilities kann man selber Aktionen in diese Event-Queue einreihen.

...und mit java.awt.EventQueue