GUI Änderungen und Threads

[Jens81]

Hallo zusammen,

ich habe eine Frage zu GUI Änderungen und Threads: Ich weiß mittlerweile, dass ich keine GUI Änderungen innerhalb von Threads durchführen darf, bzw. wenn ich dies tue muss ich sie mit invokeLater / invokeAndWait aufrufen (oder gleich einen SwingWorker verwenden).
Meine (vielleicht ja einfach zu beantwortende) Frage: Was genau sind denn (relevante) Gui Änderungen? Das Ändern eines Datensatzes im TableModel? Das Setzen eines Strings in ein JTextField? Das Setzen eines Hakens einer JCheckBox? Wie wird das abgegrenzt?

Gruß,
Jens

 

[Gastredner]

Ich denke, jede Änderung, die eine Änderung in der Anzeige der GUI nach sich zieht, ist eine relevante Änderung.

 

[Jens81]

Manche Methode (setText()?) sind doch threadsafe..?

 

[Michael...]

Das ist nicht so einfach zu beantworten.

z.B. ist die Methode setText() bei allen Komponenten die von JTextComponent erben Thread safe, setSelected() an einer JComboBox oder setText() an einem JLabel scheinbar nicht.

Auch bei Änderungen am TableModel z.B. per table.setValueAt(x,y) ist ein invokeLater o.ä. nicht notwendig, da das Neuzeichnen der Tabelle im EDT abläuft. Welcher Mechanismus dahinter steckt, k.A.

 

[Jens81]

Gilt dies nur für setValueAt?
Das Ändern im TableModel mit removeRow z.B. erfordert ein invokeLater

Wie kann ich denn rausfinden, wann ich invokeLater benötige? In der Api steht zumindest bei den Methoden nichts dazu.

 

[bygones]

Hallo zusammen,

ich habe eine Frage zu GUI Änderungen und Threads: Ich weiß mittlerweile, dass ich keine GUI Änderungen innerhalb von Threads durchführen darf, bzw. wenn ich dies tue muss ich sie mit invokeLater / invokeAndWait aufrufen (oder gleich einen SwingWorker verwenden).
Meine (vielleicht ja einfach zu beantwortende) Frage: Was genau sind denn (relevante) Gui Änderungen? Das Ändern eines Datensatzes im TableModel? Das Setzen eines Strings in ein JTextField? Das Setzen eines Hakens einer JCheckBox? Wie wird das abgegrenzt?

Gruß,
Jens

hae ? alles ist in Threads - natuerlich kannst/musst du GUI Aenderungen in Threads abwickeln.

Ich denke was du meinst ist, dass man groessere Berechnungen bzw zeitintensive Arbeiten nicht im GUI Thread laufen lassen darf, denn dann erhaelt man das schone "Gui ist eingefroren" Problem.

Wenn du ein einfaches setText('hallo') oder ein setSelected() aufrufst musst du dich um nix kuemmern.

Wenn du eine 1GB datei einlesen willst, dies in einem Progressbar anzeigen lassen willst, dann musst du dich um das richtige Threadmanagement kuemmern

 

[Michael...]

Eigentlich sollte man sicherstellen, dass non thread safe Swingmethoden im EDT aufgerufen werden. Allerdings ist es so, dass solche Methoden wie setValue, addRow, removeRow (um mal beim Bsp. JTable zu bleiben) zwar nicht thread safe sind, dahinter aber ein Listenerkonzept steckt. D.h. Änderungen am Model führen nicht zu direkten Änderungen an der GUI, sondern lösen Events aus, welche die GUI ändern und Events laufen im EDT und somit auch die Änderung an der GUI.

Und daher muss ich bygones zustimmen: problematisch ist eher, dass rechenintensive Aktivitäten den EDT blockieren und man diese daher besser in separate Threads auslagert.
Und ob jetzt ein setText oder setSelected im EDT läuft oder nicht, darüber würde ich mir auch keine allzu grossen Gedanken machen.

Zur Info: um herauszufinden ob der Code gerade im EDT läuft oder nicht, gibt's

javax.swing.SwingUtilities.isEventDispatchThread()

Und hier noch ein Bsp. wie man sieht laufen die Methoden addRow, removeRow und setValueAt zwar nicht im EDT, dass renderen der Zelleninhalte wird dann allerdings im EDT ausgeführt:

import java.awt.Component;

import javax.swing.JFrame;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import javax.swing.table.DefaultTableCellRenderer;
import javax.swing.table.DefaultTableModel;

public class EDTTest extends JFrame {
	private DefaultTableModel model;
	
	public EDTTest () {
		model = new DefaultTableModel(new Object[][] {{"Zelle1"}, {"Zelle2"}},new String[] {"Test"}) {
			public void removeRow(int row) {
				super.removeRow(row);
				System.out.println("rem: " + javax.swing.SwingUtilities.isEventDispatchThread());
			}
			
			public void addRow(Object[] object) {
				super.addRow(object);
				System.out.println("add: " + javax.swing.SwingUtilities.isEventDispatchThread());
			}
			
			public void setValueAt(Object object, int row, int column) {
				super.setValueAt(object, row, column);
				System.out.println("set: " + javax.swing.SwingUtilities.isEventDispatchThread());
			}
		};
		JTable table;
		this.getContentPane().add(new JScrollPane(table = new JTable(model)));
		table.setDefaultRenderer(Object.class, new DefaultTableCellRenderer(){
			public Component getTableCellRendererComponent(JTable table, Object value,
                    boolean isSelected, boolean hasFocus, int row, int column) {
				System.out.println("rendering: " + javax.swing.SwingUtilities.isEventDispatchThread());
				return super.getTableCellRendererComponent(table, value, isSelected, hasFocus, row, column);
			}
		});
		new Thread(new Runnable(){
			public void run() {
				while(true) {
					try {
						Thread.sleep(1000);
						model.addRow(new Object[] {"Inserted"});
						Thread.sleep(1000);
						model.setValueAt("new Value", model.getRowCount()-1, 0);
						Thread.sleep(1000);
						model.removeRow(model.getRowCount()-1);
					} catch (InterruptedException e) {
						e.printStackTrace();
					}
				}
			}
		}).start();
	}
	
	public static void main(String[] args) {
		JFrame frame = new EDTTest();
		frame.setBounds(0, 0, 500, 300);
		frame.setLocationRelativeTo(null);
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.setVisible(true);
	}
}

 

[Jens81]

Genau darum geht es ja. Es ist schon klar das alles in Threads läuft

Wenn ich nun einen zeitintensive Berechnung in einem eigenen Thread laufen lasse und während der Berechnung z.B. Zwischenergebnisse in eine TextBox schreiben möchte, oder eine Tabellenzeile ändern / löschen muss, sollte man ja wissen ob das nun in diesem Thread geschehen darf, oder ich in den EDT wechseln muss.

Das man TableModel Änderungen doch im EDt laufen lassen muss, habe ich aus diesem Thread hier: http://www.java-forum.org/awt-swing-swt/79700-jtable-auto-rowsorter-nullpointer-exception.html Dort gab es Probleme mit dem AutoTableRowSorter, wenn man die Änderungen nicht im EDT ausführt.

 

[Marco13]

Eigentlich sollte man sicherstellen, dass non thread safe Swingmethoden im EDT aufgerufen werden. Allerdings ist es so, dass solche Methoden wie setValue, addRow, removeRow (um mal beim Bsp. JTable zu bleiben) zwar nicht thread safe sind, dahinter aber ein Listenerkonzept steckt. D.h. Änderungen am Model führen nicht zu direkten Änderungen an der GUI, sondern lösen Events aus, welche die GUI ändern und Events laufen im EDT und somit auch die Änderung an der GUI.
...
Und ob jetzt ein setText oder setSelected im EDT läuft oder nicht, darüber würde ich mir auch keine allzu grossen Gedanken machen.

Das stimmt so nicht. Es werden zwar Events gefeuert, aber die werden auf dem Thread gefeuert, der auch die Änderung macht. Und DESwegen sollte man die Änderungen auch nur auf dem EDT machen. Und darum sollte man sich schon Gedanken machen. Es gibt nicht viele allgemeine "Regeln", die man bei Swing beachten muss. Aber eine (und wichtige) ist eben die "Single Thread Rule":

Once a Swing component has been realized, all code that might affect or depend on the state of that component should be executed in the event-dispatching thread. ( Threads and Swing )

EDIT: Genaugenommen ist die sogar etwas unpräzise (oder zumindest mißverständlich). Entgegen der eigentlichen Aussage dieser Regel muss oft z.B. auch schon das Erstellen der Swing-Components auf dem EDT passieren.

 

[Michael...]

Die Events werden zwar im laufenden Thread abgefeuert. Aber abgearbeitet werden sie doch im EDT? So verstehe ich zumindest folgenden Satz aus Deinem Verweis:

Most post-initialization GUI work naturally occurs in the event-dispatching thread. Once the GUI is visible, most programs are driven by events such as button actions or mouse clicks, which are always handled in the event-dispatching thread.

 

[Marco13]

Ja, der entscheidende Teil ist eben das
"...most programs are driven by events such as button actions or mouse clicks, which are always handled in the event-dispatching thread.

Wenn man in der "actionPerformed" bei einem Buttonklick sowas macht wie
[c]someTable.insertRow(n, someData);[/c]
dann passiert das schon auf dem EDT, und die Swing-Welt ist in Ordnung.

Wenn man aber in einem eigenen Thread sowas macht wie
[c]someTable.insertRow(n, someData);[/c]
dann ist der Ablauf relativ leicht nachvollziehbar:

class DefaultTableModel extends AbstractTableModel
{
    public void insertRow(int row, Vector rowData) {
        ...
        fireTableRowsInserted(row, row);
    }
}

class AbstractTableModel ...
{
    public void fireTableRowsInserted(int firstRow, int lastRow) {
        fireTableChanged(...);
    }

    public void fireTableChanged(TableModelEvent e) {
        ....
	for (int i = listeners.length-2; i>=0; i-=2) {
	    if (listeners[i]==TableModelListener.class) {
		((TableModelListener)listeners[i+1]).tableChanged(e);
	    }
	}
    }
}

Auf dem Thread, auf dem das
[c]someTable.insertRow(n, someData);[/c]
gemacht wird, wird auch das "tableChanged" vom TableModelListener (also von der JTable) aufgerufen. Das eigentliche Neuzeichnen der Table wird dann zwar durch ein repaint() ausgelöst und findet damit auf dem EDT statt, aber die anderen Änderungen an der JTable passieren eben auf diesem "falschen" Thread - wenn ein anderer Thread zufällig im gleichen Moment eine andere Änderung macht, kann's halt krachen (und tut es oft auch - sobald die Software beim Kunden laufen soll )

 

[Jens81]

Falls man eine Tabelle via Click auf den ColumnHeader per DefaultRowSorter sortiert und danach eine TableModel Änderung im falschen Thread durchführt, kracht es nicht nur hin und wieder...

Vielen Dank an alle