JFrame repaint ?

[Aiun]

hi,

folgendes Problem:

ich habe ein JFrame-Applikationsfenster, bein Onlcik auf einen Button wird eine andere (nicht-Swing) Klasse aufgerufen, die ca. 4000 Datensätze verarbeitet.

Während dieser verarbeitung währe es wichtig das der User erfährt Wieviele Datensätze verarbeitet wurden und welcher Typ (Datensätze kommen aus verschiedenen Tabellen, die ich hierarisch abarbeiten muss)

also wird vor beginn der berechnung ein JFrame aufgemacht.

JFrame

->Scrollpane

->->JTable

das ganze ist als Singleton implementiert. also mache ich sowas wie

Status.getInstance().addMessage()

und danach, damit das Scrollpane refreshed wird

Scrollpane.setViewportView(JTable)

doch leider wird das ganze erst gezeichnet, wenn die Datenverarbeitung zuende ist.

Habs als Runnable versucht und mit verschiedenen Reihenfolgen von .repaint und .dolayout

irgendwelche Ideen ?

[_Arvid_]

Ganz einfacher Lösungsvorschlag: Lasse die Verarbeitung der 4000 Datensätze in einem Thread laufen. Bei der seperaten Verarbeitung kann die JVM sich auch weiterhin um die grafischen Komponenten kümmern.

[perdian]

Lasse die Verarbeitung der 4000 Datensätze in einem Thread laufen.

Als Ergänzung noch ein paar Quellen für weitere Infos:

http://www.javapractices.com/Topic153.cjp

http://www.galileocomputing.de/openbook/javainsel4/javainsel_15_031.htm

http://www.ictp.trieste.it/~manuals/programming/Java/tutorial/uiswing/overview/threads.html

[_Arvid_]

@perdi: Danke für die Ergänzung.

Aber hier noch ein winziger Exkurs in Java-Threads.

Also: Lasse deine "nicht-Swing-Klasse" das Interface Runnable implementieren. (Warum nicht einfach die Klasse Thread erweitern? Saubere Kodier-Richtlininen sagen meistens aus, dass Interfaces bevorzugt zu benutzen sind.) Dann implementierst du entsprechend die Methode run() aus dem Interface.

public class DatensaetzeVerarbeiten implements Runnable {

	public void run() {

		// mach was

	}

}

Die Klasse, welche bei dir auf den Buttonklick reagiert, möglicherweise eine Controllerklasse oder dein JFrame selbst (oder was auch immer), lässt du dann entsprechend den Thread mit der Verarbeitung der Datensätze starten, zum Beispiel als Aufruf folgender Methode:

public void starteSuche() throws Exception {

	Thread verarbeitung = new Thread(new DatensaetzeVerarbeiten());

	verarbeitung.setDaemon(true);

	verarbeitung.start();

}

Das sollte dann auch schon reichen (so ganz grob).

[Aiun]

Alles noch sehr verwirrend...werde mir das wohl noch eine weile ansehen müssen.

Meine main-Klasse erstellt erst eine Datenbankverbindung, ruft dann das Haupt-JFrame auf und die berechnung geht los.

Ich muss meine Statusmeldungen in der Main-Klasse auch mit InvokeLater(..) abschicken...dann ging es.

danke auf jeden fall

[M.A.Knapp]

Ich mache das so:

Es gibt ein Interface "ProgressState"

public interface ProgressState

{

public void setProgress(int i, int n); // i von n dingen erledigt

}

und ein Fenster, der den Progress-Bar, .. etc. enhält und

dieses Interface implementiert

ProgressFrame extends JFrame implements ProgressState

{

}

Zum Schluß der Thread, der Daten verarbeitet, dem das Interface übergeben wird:

ProcessingThread extends Thread

{

private ProgressState ps;

public ProcessingThread(ProgressState ps) { this.ps = ps; }

public void run( .... ps.setProgress(i, n); ... }

}

Aufruf sieht dan so aus:

ProgressFrame pf = new ProgressFrame();

Pf.setVisible(true);

ProcessingThread pt = new ProcessingThread(pf);

pt.start();

[_Arvid_]

Ich mache das so: ....

Und Sun macht das so:

http://java.sun.com/docs/books/tutorial/uiswing/components/progress.html

Aber ich glaube, darum ging es hier eigentlich (noch) nicht. Aiun hat offenbar an der Nebenläufigkeit des Prozesses zu knabbern, um überhaupt dafür zu sorgen, dass die grafische Oberfläche weiterhin reagieren/sich neu zeichnen kann.

Die Anzeige des Bearbeitungsfortschritts in Form eines Statusbalken und/oder in Form von Ausgaben waren bislang nicht von Bedeutung.

Alles noch sehr verwirrend...

Was bereitet dir denn noch Schwierigkeiten? Grundsätzliche Probleme mit der Thematik Threads oder sind es bereits Detailfragen?

[M.A.Knapp]

Ansich ist es einfach, die "Reactivity" der Oberfläche zu erhalten: Man darf nichts machen, was den AWT/Swing Message-Dispatcher blockieren könnte, d.h keine länger dauernden Operation in von AWT/Swing aufgerufenen Listenern, z.b actionPerformed von ActionListener durchführen. Alles was längert dauert sollte daher in Threads ausgelagert werden.

MfG, Michael

[_Arvid_]

Ansich ist es einfach ... Man darf nichts ... von ActionListener durchführen....

... Das könnte sich in diesem Fall gewissermaßen als schwierig heraus stellen:

bein Onlcik auf einen Button wird eine andere (nicht-Swing) Klasse aufgerufen

Und das, da gebe ich dir natürlich recht, wird ...

in Threads ausgelagert

Aber ist das keine neue Erkenntnis. Eben darum geht es ja. So weit waren wir also schon.

Naja, ich bin müde, werd jetz neue Energie für den morgigen Tag sammeln. Tschö mit ö. Und gute Nacht.

[M.A.Knapp]

Und wo liegt dann das Problem ?