Swing [gelöst] GUI-Befehle bleiben wirkungslos, wenn danach was großes gemacht wird.

[Skalarprodukt]

Hi,

in meiner Applikation wird durch einen Knopfdruck eine ggf. lange (da rekursive) Berechnung durchgeführt. Damit der User sieht, das gerade was passiert, möchte ich die GUI deaktivieren (mit bla.setEnabled(false)) und einen kleinen Text in ein vorhandenes JTextArea ("Vorgang wird berechnet") packen. Klarer Fall:

	public class GoButtonListener implements ActionListener {

		public void actionPerformed(ActionEvent pE) {
			_viewController.setGuiEnable(false); //ruft bei den gui-komponenten den setEnabled(boolean) auf
			_evaluationTextArea.setText("Wird verarbeitet");

			// hier kommen viele, lange Berechnungen...

			_evaluationTextArea.setText(_auswertungsString);
			_viewController.setGuiEnable(true);
		}

Doch leider, wird die GUI nicht deaktiviert, der Text nicht gesetzt, sondern gleich losgerechnet. Nehme ich die Berechnung raus, so wird die GUI brav deaktiviert. Wie ist dieses Verhalten zu erklären?

 

[SlaterB]

Threading with Swing

steht dort bisschen versteckt und nicht ausführlich,
kurz gesagt: lange Aktion in neuem Thread ausführen

->
Constructing Threads and Runnables in Java

 

[Verjigorm]

Du brauchst einen eigenen Thread dafür

 

[Skalarprodukt]

OK ich habs jetzt hinbekommen, aber leider verstehe ich immer noch nichts ganz das Warum.

Also ich habs so verstanden: GUI-Interaktion bzw. das gesamte Listening wird in dem sog. Event Dispatch Thread ausgeführt (das gilt auch für mein actionPerformed()). Nun habe ich dort aber meine lange Berechnung drinne, was den Thread natürlich beansprucht, sodass er nicht mehr auf weiter GUI-Interaktionen reagiert. Soweit so gut, aber warum konnte ich die GUI dann nicht disablen? Ich habe den Befehl doch vor (!) der langen Berechnung gegeben. Oder seit wann wird die 3. Anweisung vor der 1. und 2. ausgeführt??

Weitere komische Sache: Wenn einen neuen Thread "händisch" starte:

		public void actionPerformed(ActionEvent pE) {
			_viewController.setGuiEnable(false);
			_evaluationTextArea.setText("Wird verarbeitet");

			Runnable runnable = new CountLinesRunnable();
//			SwingUtilities.invokeLater(runnable);
			Thread thread = new Thread(runnable);
			thread.run();

		}

wird die GUI auch nicht deaktiviert, warum das? Ich starte die Rechnung doch im eigene Thread, sodass der Event Dispatch Thread wieder frei ist, um die GUI zu deaktiveren. Lediglich das Starten über SwingUtilities.invokeLater(runnable) bringt das gewünschte Verhalten... das versteh ich nicht.

 

[SlaterB]

was bedeutet
> _viewController.setGuiEnable(false);

einen solchen Befehl in der Luft kann niemand beurteilen,
wie stellst du fest, ob die GUI enabled ist oder nicht? wenn sie blockiert kannst eh nichts mit der GUI machen,
neu gezeichnet wird auch nicht, so lange blockiert ist, falls du das meinst,

> Wenn einen neuen Thread "händisch" starte:

run() führt nur die Methode nomal aus,
start() startet per Magie einen eigenen Thread

> Lediglich das Starten über SwingUtilities.invokeLater(runnable) bringt das gewünschte Verhalten...

damit wird der ActionListener sogleich beendet, die Auswirkungen von setGuiEnable() können umgesetzt werden,
und danach kommt dann CountLinesRunnable dran,

da während dessen Ausführung dann die GUI blockiert ist, ist das aber keine wirklich Alternative, lieber den Thread richtig starten

 

[Skalarprodukt]

Vielen Dank für deine Antwort.

Hab jetzt die ganze Materie durchdrungen.

Der Event Dispatch Thread kümmert sich um Dinge wie das Repaint und das ausführen des Eventhandlings, zb. der actionPerformed()-Methode. Wenn ich nun eine aufwändige Berechnung im actionPerformed() habe, so wird diese vom Event Dispatch Thread ausgeführt, während dessen kann er aber nicht die GUI repainten, sodass GUI-Änderungen (knopf.setEnabled(false) etc.) zwar vermerkt sind, aber (noch) keine Wirkung zeigen.

SwingUtilies.invokeLater(Runnable) schiebt ein run-Vorgang in den Event Dispatch Thread (genauer gesagt, wird dieser nach actionPerformed() ausgeführt), daher erfüllt das zwar meinen zweck, ist aber nicht besonders hübsch, da während dessen keine GUI-Interaktion möglich sind.

Lange Rede kurzer Sinn: Einfach einen separaten Thread mit start() (;-)) starten, in welchen dann die GUI am Ende wieder aktiviert wird und dann klappts auch mit dem Nachbarn. =)

So Danke an SlaterB und meinem OOP-Dozenten.

PS: mein setGuiEnabled(boolean) hat lediglich eine Reihe von Befehlen wie knopf.setEnabled(boolean); gekapselt.