Swing Update von swing-TableModels per Thread. Eins geht, das andere nicht, warum?

[Collinwood]

Hallo Ihr Lieben,

ich versuche mit diesem Thread 2 TableModels zu aktualisieren, was mir auch zur Hälfte super gelingt.
Anlass des ganzen war, dass ich festgestellt habe, dass mein eigentlicher Arbeitsthread zwar fertig läuft, jedoch die Tabellen sich dann nur per Klick in die Zellen aktualisieren lassen, und das finde ich, auch wenns ein Programm zur eigenen Verwendung werden soll, usability-technisch recht unschön.

So kam ich also dazu, für die regelmäßige Ausführung der fireTableDataChanged-Methode auf die Tabellenmodelle, eben auch einen eigenen Thread zu verwenden.

Die rechte Tabelle aktualisiert sich wunderschön, die mittlere irgendwie gar nicht.
Kennt sich da jemand aus, woran das liegen könnte? Ich hab es schon mit einer höheren Sleep-Zeit probiert (5 Sekunden), aber das hatte auch keine Auswirkungen.

Im folgenden der Code, und im Link ist in der Zip-Datei ein kleines fraps-Video und ein ordentlicher Screenshot, damit ihr auch seht, von was ich spreche.
http://tok.keiler-land.de/tempfiles/paket.zip

Vielen Dank vorab für eure Hilfe!

package gui;
 
import javax.swing.table.AbstractTableModel;
import javax.swing.table.TableModel;
 
public class UpdaterThread extends Thread {
 
    private TableModel dtm;
    private TableModel dtm2;
 
    public UpdaterThread() {
 
    }
 
    public void run() {
        while (!Thread.interrupted()) {
            //System.out.println("updating gui...");
            if (this.dtm != null) {
                ((AbstractTableModel) this.dtm).fireTableDataChanged();
                ((AbstractTableModel) this.dtm2).fireTableDataChanged();
            }
 
            try {
                Thread.sleep(25);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
    }
 
    public TableModel getDtm() {
        return this.dtm;
    }
 
    public void setDtm(TableModel dtm) {
        this.dtm = dtm;
    }
 
    public TableModel getDtm2() {
        return this.dtm2;
    }
 
    public void setDtm2(TableModel dtm2) {
        this.dtm2 = dtm2;
    }
}

P.S. updater.start() wird gleich zu Beginn des Programms aufgerufen, und die beiden Setter rufe ich dann erstmalig auf, wenn die Tabellen überhaupt befüllt werden. Die Nullpointer-Exception verhindere ich ja mit der entsprechenden Abfrage.

 

[turtle]

Du weißt, das eine Swing-GUI nur vom EDT (Event-Dispath-Thread) geändert werden kann?

Daher kommen mir Zeilen wie

((AbstractTableModel) this.dtm).fireTableDataChanged()

in einem Thread merkwürdig vor

 

[Collinwood]

Hi turtle,

vielen Dank für deine Antwort!

Du fragtest:

Du weißt, das eine Swing-GUI nur vom EDT (Event-Dispath-Thread) geändert werden kann?

Nein, so gut kenne ich mich da leider echt nicht aus. GUI ist seit Jahren bei mir immer viel Bastelwerk und Learning by Doing. Liegt daran dass ich schlecht im Theoretischen Lernen bin und mir deshalb niemals seitenlange abstrakte Erklärungen antue, die ziemlich in die Tiefe gehen ohne dass man Ahnung hat, was der Autor wirklich von einem will.

Daher kommen mir Zeilen wie

((AbstractTableModel) this.dtm).fireTableDataChanged()

in einem Thread merkwürdig vor

Ich glaube da solltest du eine Stufe herab schalten - ich habe ja auch angegeben, dass ich maximal "Fortgeschrittener" bin. Deine Antwort setzt hier ziemlich was voraus. Das kann man bei (Semi-)Profis machen, aber ich hab jetzt so von der Hilfe erstmal wenig.
Vielleicht gelingt es dir ja, mir zu erklären, wie ich den EDT sinnvoll anwende, um das gewünschte Ziel zu erreichen?

 

[rme]

Hallo

In Swing ist es so, dass Änderung an GUI-Elementen nur aus Swing selbst heraus passieren dürfen, weil man auf eine Synchronisierung verzichtet hat. Das bedeutet, dass bei der Benutzung von Threads selbst dafür gesorgt werden muss, dass die Änderungen an GUI-Elementen in Swings eigenem Thread passieren, statt wild aus anderen Threads heraus. Dafür gibt es aber eine Hilfsmethode, die man folgendermaßen einsetzt:

SwingUtilities.invokeLater(new Runnable() {
    public void run() {
        // hier Code, der auf GUI-Elemente zugreift
    }
});

In deinem Fall müssen die Mitteilungen an die Listener (diese fire..-Methoden) in so einem Block gekapselt sein.

 

[Collinwood]

Hallo rme,

danke für deine Antwort!

Genauso hatte ich es zuerst implementiert. Da passiert aber auch das, was ich eingangs beschrieben habe. Die Aktualisierung findet statt, wenn mein anderer Thread fertig ist...

Die Methode macht übrigens genau was sie vom Namen her verspricht: invoke later - ruf es später auf... das interpretiere ich als, "Ruf es dann auf, wenn hier alle anderen mit ihrer Arbeit fertig sind, und die GUI-Elemente ganz sicher in Ruhe gelassen werden". Wahrscheinlich weil swing einfach nicht "thread-safe" ist, soviel hab ich mittlerweile mitbekommen.

Die Aktualisierung möchte ich aber währenddessen. Da ist jetzt die Frage, muss ich

a) den "Arbeitsthread" so einstellen, dass er zwischenzeitlich immer wieder "loslässt", also das System freigibt? Das würde ich ja mit kurzen sleeps erreichen (ähnlich wie in DIESEM UpdaterThread 25 millis), oder liege ich da falsch?

b) tatsächlich auf AWT oder SWT migrieren?

c) was ganz anderes tun...?

Bitte teile mir mit, was der günstigste und schadenfreieste Weg ist. Danke!

 

[rme]

invokeLater führt den Code aus, sobald die GUI nichts anderes zu tun hat - normalerweise also quasi sofort. Das Problem muss also woanders liegen, aber dafür sehe ich zu wenig Code - insbesondere, wie die beiden Threads miteinander kommunizieren usw.

Wie gelangen die Daten denn in die beiden TableModels? Das macht vermutlich der andere Thread? Das wäre dann ebenfalls problematisch, weil sich die Daten dann ändern können, während Swing sie gerade auslesen möchte.. sowas ist nur schwierig zu synchronisieren.

Falls du etwas genauer beschreiben kannst, was deine Anwendung tun soll, könnte man dir möglicherweise bessere Tipps geben, denn dein momentaner Ansatz mit den 2 Threads ist glaube ich kein guter, sodass es besser wäre, dir einen anderen vorzuschlagen.

 

[Collinwood]

Habe gerade mit dem Smartphone noch ein wenig auf der couch gegoogelt und stelle fest dass invokelater einen synchronen Bruder namens invokeandwait hat, der den Versprechungen nach genau das können soll was ich will... Ist das der Schlüssel zum Erfolg? Wenn ja, würde ich das morgen mal ausprobieren!

 

[rme]

Das würde deinen Thread blockieren, bis Swing die Daten übernommen hat. Aber auch das löst nicht das Problem, dass fireTableDataChanged Swing ja nur mitteilt, dass sich etwas geändert hat und der andere Thread gerade gleichzeitig eine weitere Änderung am Model machen kann, wodurch manchmal alles kaputtgehen würde..

 

[Collinwood]

Hmpf... shi* das hört sich ja verzwickt an.

Du, ich bin jetzt nicht mehr an dem Rechner mit dem ich programmiere und leider hab ich immer noch kein Repository auf meinem NAS eingerichtet, wie ich das eigentlich seit Monaten machen will

Ich hab eigentlich kein Problem damit, dir morgen den ganzen Quellcode zu übersenden, aber wobei ich mich unwohl fühle, ist, das öffentlich im Forum zu tun. Nicht aus Gründen der Geheimhaltung, es ist ja ein privates Projekt und von mir aus verteil ich das fertige Produkt an die ganze Welt; aber wovor ich etwas Schiss habe sind die ganzen Kommentare zum restlichen Code. Hier meint dann plötzlich jeder, mir alles durchkorrigieren zu müssen "weil man so nie programmieren würde" - schon oft genug gehört.

Nun gut, da jede andere Regelung wohl gegen die Forenrichtlinien verstoßen würde, poste ich morgen alles. Ich versuche dann den Fokus auf dem Problem zu halten und sonstiges zu ignorieren

 

[rme]

Den Code brauchen wir doch gar nicht Wir wollen einfach nur wissen, was das Programm ungefähr tun soll, damit eine Lösung vorgeschlagen werden kann, die ohne Threads auskommt - das ist nämlich häufig immer der Fall. Es wäre zum Beispiel ohne Threads möglich, eine Datei laufend auf Änderungen zu überwachen und den Inhalt in einer Swing-Tabelle auszugeben.. wenn du deine Aufgabe auf diesem Niveau kurz beschreibst, fällt uns bestimmt eine einfache Lösung ein.

 

[Collinwood]

Hallo rme,

ich hab jetzt einfach das ganze Projekt gepackt und als Anhang hochgeladen.

Außerdem habe ich festgestellt, dass die Threads nicht das eigentliche Problem sind.
Und zwar schau dafür am besten direkt mal in die Klasse "Launcher" rein, welche auch die Main() enthält. (Siehe Zeile 95 - das ist Original und die // Zeile 96 wäre die Probe)
Ich habe dort spaßeshalber ausprobiert, einem Tabellenmodell eine andere Liste ("Kartenliste") beim instanziieren mitzugeben. Und siehe da, es wird anstandslos aktualisiert.

Was das Tool machen soll, kurz und knapp. Es gibt da ein Brettspiel namens Dominion, welche alleine im Basisspiel unzählige Spielkombinationen enthält, da du immer mit 10 Karten als eine Auswahl aus (im Basisspiel zB 26) vielen Karten spielst. Hat man jetzt noch diese und jene Erweiterung (insgesamt gibt es wohl eine weitere Basis und 6 Erweiterungen) erhöht sich die Anzahl möglicher Spielkombinationen auf 3 Billiarden.

Da hab ich mir gedacht, wäre doch cool wenn man in geselliger Runde ein Tool hätte, was einem Spielvorschläge auf Basis vieler verschiedener Parameter und Einstellungen unterbreitet.
Das ist bis jetzt dabei herausgekommen, durch hin und wieder sporadische Arbeit daran.

[Wie schon erwähnt, ich bin kein Java-Guru und erst Recht kein GUI-Champion, daher arbeite ich da momentan mit Hilfsmitteln und Methoden die sich im Laufe der Zeit einfach bewährt haben.]

Das Tool besteht im Grund aus 3 sichtbaren Tabellen, liest eine csv-Datei mit Kartenwerten ein und stellt diese erstmal im "Pool" ganz links dar. Dann kann man sich eine Auswahl generieren lassen (hirnloses Shuffle) und auf Basis dessen gibt es dann bis jetzt verschiedene Balancing-Verfahren, die sich über den Slider und die zugehörigen Buttons in der Mitte bedienen lassen.

Das Ergebnis, worum es in diesem Thread geht, soll dann stattfinden, wenn man im Feld "Rückschrittlänge" eine 0 eingibt und den Slider mal einfach auf 100 stellt. Bedeutung: Es werden so lange neue Spielvorschläge generiert, bis der gewünschte Sliderwert erreicht ist. 100 ist unmöglich, wenn auch nur ein Kartenwert zu den anderen unterschiedlich ist. Das würde bedeuten, dass das gewählte Kartenset im Vergleich zum Durchschnitt ALLER Karten zu 100% ausbalanciert, also "Durchschnitt Spielkarten" und "Durchschnitt alle Karten" identische Werte aufweisen, und das in jedem Parameter. Während dieser Prozess also läuft, möchte ich, dass sich möglichst viel auf dem Tool bewegt. Die Progressbar läuft zB tadellos und die Spielvorschlagstabelle wird auch super aktualisiert. Nur halt der "Mix-Pool" in der Mitte nicht.

Und da habe ich ja eingangs erwähnt das das Threading hier wohl gar nicht problematisch ist, sondern irgendwo ein Kompatibilitätsproblem zwischen dem "mittleren" Tabellenmodell und der "mixedCardList" vorherrscht. Ist jetzt nur ne Vermutung, aber die Probe spricht dafür...

Achso, ganz wichtig, im Anhang liegt auch noch die csv-Datei, ohne die geht nix! Da gibts auch noch keinen FileChooser oder ein Auffangen der Exception - nee nee, wie gesagt, das Ding ist ja noch lang net fertig.

Aber schon mal vielen Dank für das weitere Analysieren des Problems!

Viele Grüße

 

[rme]

Hallo,

leider ist das Encoding deiner Dateien fehlerhaft, weshalb ich das Programm nicht kompilieren kann. Aber da sich Variablennamen wie a, b, c, d usw. durch den Code ziehen, würde ich das vermutlich auch dann nicht verstehen, wenn du das Encoding reparieren würdest

Da es anscheinend auch nichts meht mit Threads zu tun hat, folgender Vorschlag: Reduzier deinen Code auf ein ausführbares Minimalbeispiel, sodass man sich ein Bild von dem Problem machen kann und Lösungen direkt ausprobieren kann - und das dann in einem neuen Beitrag im Forum.

 

[turtle]

Ich habe mal eine kleine Demo nach dem Vorbild meines Blog geschrieben und dieses mischt alle Zeilen des Table-Model durcheinander bis irgendwann auf Stop geklickt wird.
Ist wohl nicht elegant gelöst, sondern nur quick-and-dirty

import java.awt.BorderLayout;
import java.awt.event.ActionEvent;
import java.awt.event.ActionListener;
import java.util.List;
import java.util.Random;
import java.util.Vector;

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTable;
import javax.swing.SwingWorker;
import javax.swing.table.DefaultTableModel;

public class SampleTable extends JPanel {
	private final JTable table;
	private final MeinModel model;

	public SampleTable() {
		model = new MeinModel(4);
		table = new JTable(model);
		add(new JScrollPane(table), BorderLayout.CENTER);
	}

	public JTable getTable() {
		return table;
	}

	public MeinModel getModel() {
		return model;
	}

	public static void main(String[] args) {
		JFrame frame = new JFrame("Table");
		frame.setLayout(new BorderLayout());
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		SampleTable sampleTable = new SampleTable();
		frame.add(sampleTable, BorderLayout.CENTER);
		JButton btnShuffle = new JButton("Shuffle");
		final MeinShuffler meinShuffler = new MeinShuffler(
				sampleTable.getTable(), sampleTable.getModel());
		btnShuffle.addActionListener(meinShuffler);
		frame.add(btnShuffle, BorderLayout.NORTH);
		JButton btnStop = new JButton("Stop");
		btnStop.addActionListener(new ActionListener() {

			@Override
			public void actionPerformed(ActionEvent e) {
				meinShuffler.cancel(true);
			}
		});
		frame.add(btnStop, BorderLayout.SOUTH);
		frame.pack();
		frame.setVisible(true);
	}
}

class MeinShuffler implements ActionListener {
	private final JTable table;
	private final MeinModel model;
	private ShuffleModel worker;

	public MeinShuffler(JTable table, MeinModel model) {
		this.table = table;
		this.model = model;
	}

	public void cancel(boolean b) {
		worker.cancel(b);
	}

	@Override
	public void actionPerformed(ActionEvent e) {
		worker = new ShuffleModel(table, model);
		worker.execute();
	}
}

class MeinModel extends DefaultTableModel {
	public MeinModel(int anzahl) {
		columnIdentifiers = new Vector<String>();
		dataVector = new Vector<String>();
		for (int i = 0; i < anzahl; i++) {
			columnIdentifiers.add("Spalte " + i);
		}

		for (int zeile = 0; zeile < 10; zeile++) {
			Vector<String> oneRow = new Vector<String>();
			for (int i = 0; i < anzahl; i++) {
				int zelle = i + 4 * zeile;
				oneRow.add("" + zelle);
			}
			dataVector.add(oneRow);
		}
	}

	public void shuffle() {
		Random random = new Random();
		for (int i = 0; i < 100; i++) {
			int maxAnzahl = dataVector.size();
			int src = random.nextInt(maxAnzahl);
			int nach = random.nextInt(maxAnzahl);
			List<String> contentSrc = (List<String>) dataVector.get(src);
			List<String> contentDest = (List<String>) dataVector.get(nach);
			dataVector.setElementAt(contentSrc, nach);
			dataVector.setElementAt(contentDest, src);
		}
	}
}

class ShuffleModel extends SwingWorker<Void, MeinModel> {
	private final JTable table;
	private final MeinModel model;

	public ShuffleModel(JTable table, MeinModel model) {
		this.model = model;
		this.table = table;
	}

	@Override
	protected void process(List<MeinModel> chunks) {
		for (MeinModel meinModel : chunks) {
			meinModel.shuffle();
			table.setModel(meinModel);
			meinModel.fireTableStructureChanged();
		}
	}

	@Override
	protected Void doInBackground() throws Exception {
		while (!isCancelled()) {
			publish(model);
			Thread.sleep(1000);
		}
		return null;
	}
}