Swing GUI-Thread für automatisches Update nutzen

[Frank_10001]

Ich versuch gerade Daten die ich generiere irgendwie auf ein Textfeld auszugeben.

Das Problem das ich dabei habe, entweder ich muss dem generierenden Objekt eine REferenz auf das Textfeld geben um per setText die Daten zu schreiben, oder ich brauch eine Art Vermittlerklasse (Logger im eignen Thread) die das erledigt, was ich aber nicht möchte!

Ich würde viel lieber die Textfeldklasse umschreiben, damit sie sich die Daten von dem Datenobjekt selbst abholt! Ich habe es mit der paint-Methode versucht, aber durch die setText Funktion generier ich nur eine endlose Updateschleife, welche Funktion vom Textfeld kann ich also umschreiben damit ich dennnoch eine performante und schnelle Updaterate habe ohne einen zusätzlichen Thread zu starten oder meinen Datenthread mit setText aufrufen zu bremsen?

Vielleicht seh ich auch den Wald vor lauter Bäumen nicht ^^

 

[Michael...]

Idamit sie sich die Daten von dem Datenobjekt selbst abholt!

Das hört sich nach MVC oder Observer Pattern an.

Ich habe es mit der paint-Methode versucht

Wieso die paint überschreiben?

damit ich dennnoch eine performante und schnelle Updaterate habe ohne einen zusätzlichen Thread zu starten oder meinen Datenthread mit setText aufrufen zu bremsen

Also existiert bereits ein zusätzlicher Thread zum Lesen der Daten?

 

[vanny]

Auch wenn deine Beschreibung ziemlich wirsch ist, schau dir mal das MVC-Pattern an.

 

[Frank_10001]

exakt, MVC pattern ...

aber ich weis irgendwie nicht so recht wo ich bei der GUI ansetzen soll damit ich eine halbwegs performante Übertragung der Daten aus den Datenobjekt (mit eigenen Thread) in die GUI bewerkstelligen kann. Irgendwie hab ich grad n Brett vorm Kopf ....

 

[Frank_10001]

Entschuldigung für den doppelpost ... ich mach mir nachher gleich nen Account fürs Editieren

Sorry auch für die unklare Erklärung, ich hab grad n Knoten im Hirn und hoffe auf Hilfe.

Ich wollte aber noch ergänzen, dass ich möglichst keinen Link von der GUI im Model haben will, also quasi soll die GUI sich die Daten ausschliesslich über eine API vom Model holen, aber eben möglichst ohne einen separaten Thread zu starten ich weis nur nicht wo ich da ansetzen soll!

 

[Michael...]

Ich wollte aber noch ergänzen, dass ich möglichst keinen Link von der GUI im Model haben will

Darf es denn ein Interface sein? Die GUI kann sich als "ModelListener" am Model registieren. Umgekehrt kann die GUI natürlich auch nur das Interface des Models kennen.

 

[Frank_10001]

Interessante Idee, aber mit dem Aufruf des überschriebenen ModelListener würde cih mir dennoch wieeder die setText Aufrufe in den Kontext des Datenthread holen und diesen damit bremsen, was ich tunlichst vermeiden muss!

Mir ist da gerade der Gedanke gekommen einen Timer im GUI Kontext zu starten (hab ich bei Borland C++ zumindest mal so gemacht) um die Daten abzurufen, Problem dabei war irgendwann dass der Timer eine gewisse nervtötende Grundlast der GUI provozierte! Ich würde am liebsten eine ständig laufende Operation der GUI (die paint-Methode z.b.) dafür nutzen welche nur dann aktiv ist wenn ich das Objekt auch sehe, aber die setTExt-Funktion löst ja automatisch ein repaint aus und damit eine Endlossschleife

Wahrscheinlich muss ich eher in de sauren Apfel beissen und mir doch einen Logger mit Listener und eigenem Thread-Kontext bauen um die Daten in die GUI zu schaufeln! Auch wenn es mir missfällt da einen eigenen Thread für aufzumachen, im Load-Balancing hab ich leider keine Erfahrung!

 

[Michael...]

Um da Empfehlungen zu geben, wüsste man genauer wissen was das werden soll und welche Voraussetzungen gegeben sind.

Du hast eine kontinuierliche Datenabfragen? Und willst danach immer einen Wert in einem JTextField aktualisieren? Ein einfaches setText(...) sollte normalerweise nicht allzu lange benötigen. Evtl.:

SwingUtilities.invokeLater(new Runnable() {
	public void run() {
		textField.setText(newValue);
	}
});

Werden dabei evtl. mehrere Strings mit "+" verkettet? Das kann durchaus auf die Performance gehen.

 

[bERt0r]

Ich hab dir ein Beispiel geschrieben: Anhang anzeigen MVCDemo.jar

 

[Nopileos]

so, hab mir erstmal nen Account angelegt, macht es deutlich einfacher zu editieren und Ergänzungen zu schreiben

der Gedanke mit invokeLater ist perfekt! Ich machs jetzt über einen Listener und im überschriebenen Listener mach ich es dann über invokeLater (sofern später nicht irgendwer einen dämlichen FEhler macht und OHNE invokeLater arbeitet sollte es auch gut funktionieren), so updatet er im GUI Kontext und das sogar recht häufig ohne dabei unnötig repaints auszulösen!

als ich es gelesen hatte fiel es mir auch wieder wie Schuppen von den Augen ... da arbeitet man ein Jahr lang mal mit Labview und vergisst schon die grundlegenden Mechanismen ... Ich rate jedem von Labview ab der ein Anständiges Programm erstellen will ... schlagt euch lieber mit irgendwelchen TReiberschnittstellen rum oder baut eine Schnittstelle zu Labview als das ganze Programm in LV zu schreiben!

 

[lumo]

auch wenns etwas spät kommt...
wie wärs mit javabeans -> deine datenklassen in ein javabean umwandeln, dann einen observer den du auf deine datenklasse registierst -> dann wird bei jeder änderung in deiner datenklasse automatisch der gui mit aktualisiert...

das wird wohl performanter sein, als in einem eigenen thread alle paar sec/ms daten zu lesen und dann in das textfeld schreiben (wenn da ev. sogar noch das selbe drin steht...)

edit: wenn das gui in JFace/SWT wäre könntest du JFace Databinding verwenden... EMF ist auch einen tolle sache (hab ich aber nur mit SWT verwendet)