VisualBasic Threading

mabstrei

Cadet 4th Year
Registriert
Juli 2008
Beiträge
79
Hi möchte in einem Form einen thread starten der mir andauernd einen listview mit daten versorgt und die immer aktuell hält (quasi endlos)

kann mir jemand helfen wie ich das hinbekomme
 
Mit ´nem Timer? Oder am besten wäre das Event, was ein neues Item zur Folge hätte, so zu nutzen, dass es gleich das Item hinzufügt.
Eine Endlosschleife für einen ganzen CPU-Kern sinnlos verbrennen.
 
1.) Standardmäßig kann auf GUI Elemente nur in dem Thread, in dem sie erstellt wurden schreibend zugegriffen werden und das hat auch einen guten Grund. In dem Subthread wird du nur Probleme haben.

2.) Wie schon gesagt ein Endlosschleife ohne Thread.Sleep zu bauen kann ziemlich ins Auge gehen. Mit mehreren Kernen geht das zwar, aber wenn man Pech hat und die Software auf einem Rechner mit nur einem Kern läuft, dann kann es passieren, dass der eine Thread aus irgendeinem Grund höher priorisiert ist und das GUI komplett einfriert. Einmal abgesehen davon ist es nicht unbedingt ressourcenschonend.

3.) Ich mache es immer so, dass ich einen Timer habe (meistens 100ms), der mir das GUI aktualisiert. Das reicht für den User und bringt in manchen Fällen sogar einiges an Performance z.B. in einer RichtTextBox, wo einiges an Text eingefügt wird. Da macht es schon einen Unterschied, ob man 100 mal eine Zeile eingefügt wird (und dafür jedes Mal ein eigener String erzeugt wird) oder ob man alle 100ms alles sammelt und dann auf einmal einfügt.

4.) Du solltest dir zuerst einmal überlegen, wie viele Daten in dem Listview stehen können und wie lange das maximal dauern kann und wenn möglich solltest du auch überlegen, was passiert, wenn sich die Umgebung ändert z.B. ob es möglich ist, dass zwischen dir und der Datenbank noch eine Internetleitung per VPN liegt. Da sind 100ms dann doch zu wenig und du solltest es lieber manuell aktualisieren.
 
andr_gin schrieb:
1.) Standardmäßig kann auf GUI Elemente nur in dem Thread, in dem sie erstellt wurden schreibend zugegriffen werden

nun ja so ist das nicht richtig, in .net 1.1 (VS2003) war es sehr wohl ohne weiteres moeglich
, da hatte MS wohl noch einen Fehler in der Implementierung ;)

Seit .net 2.0 muss wenn von einem anderen Thread in ein GUI element geschreiben werden soll, das mit einem INVOKE geschehen...



andr_gin schrieb:
4.) Du solltest dir zuerst einmal überlegen, wie viele Daten in dem Listview stehen können

Das ost eine sehr gute Frage, wieviele koennen Elemente kann das Control den aufnehmen.( Items.Count ist vom Typ int32, damit kann er es sich leciht ausrechnen)
 
Völlig falscher Ansatz, zu versuchen, die View durch pollen aktuell zu halten.
Du solltest dich lieber an das MVC Pattern halten und eine saubere Trennung zwischen Model und View haben. Views sollten prinizipiell durch Events aktualisiert werden.
 
olampl schrieb:
nun ja so ist das nicht richtig, in .net 1.1 (VS2003) war es sehr wohl ohne weiteres moeglich
, da hatte MS wohl noch einen Fehler in der Implementierung ;)

Seit .net 2.0 muss wenn von einem anderen Thread in ein GUI element geschreiben werden soll, das mit einem INVOKE geschehen...

Das ost eine sehr gute Frage, wieviele koennen Elemente kann das Control den aufnehmen.( Items.Count ist vom Typ int32, damit kann er es sich leciht ausrechnen)

Naja, du kannst auch in .NET 2.0 weiterhin aus anderen Threads auf Controls auf dem Formular schreibend zugreifen. Mußt nur die Eigenschaft "CheckForIllegalCrossThreadCalls" der Control-Klasse auf false setzen :D
 
MacGyver schrieb:
Mußt nur die Eigenschaft "CheckForIllegalCrossThreadCalls" der Control-Klasse auf false setzen :D

Na, da gefaellt mir das Invoke besser und hole mir weniger "Kaefer" ins Prog. Und es ist auch eine Legitime Loesung, Pattern sind wichtig, man sollte sie einhalten wenn moeglich.

Jedoch ist das mit dem Invoke auch eine valide Loesung. nachzulesen auf der MSDN :)
 
SheepShaver schrieb:
Völlig falscher Ansatz, zu versuchen, die View durch pollen aktuell zu halten.
Du solltest dich lieber an das MVC Pattern halten und eine saubere Trennung zwischen Model und View haben. Views sollten prinizipiell durch Events aktualisiert werden.

In diesem Beispiel der völlig richtige Ansatz. Auch wenn die View z.B. durch einen pollenden Timer aktuell gehalten wird.

Warum? Weil der Rechenknecht garnicht weiß, wie oft er ein Event auslösen soll. Jede Entscheidung hier ist willkürlich und hochgradig variabel von System zu System. Entweder leidet die Reaktionsfreudigkeit der Oberfläche oder die Performance.

Beim Pollen wird (in diesem Fall, wohl gemerkt) die GUI durch ihr eigenes, für den Benutzer sinnvolles Timing aktuell gehalten und nicht durch obskure Annahmen in irgendwelchen Algorithmen oder Entscheidungslogiken.
 
Leute ich wollte nur mal sagen, dass der Threadersteller sich seit der Eröffnung vor 4 Tagen sich nichtmehr gemeldet hat.
 
7H3 N4C3R schrieb:
In diesem Beispiel der völlig richtige Ansatz. Auch wenn die View z.B. durch einen pollenden Timer aktuell gehalten wird.

Warum? Weil der Rechenknecht garnicht weiß, wie oft er ein Event auslösen soll. Jede Entscheidung hier ist willkürlich und hochgradig variabel von System zu System. Entweder leidet die Reaktionsfreudigkeit der Oberfläche oder die Performance.

Beim Pollen wird (in diesem Fall, wohl gemerkt) die GUI durch ihr eigenes, für den Benutzer sinnvolles Timing aktuell gehalten und nicht durch obskure Annahmen in irgendwelchen Algorithmen oder Entscheidungslogiken.
Ahem, die Events werden normalerweise vom Datenmodel ausgelöst. Und zwar nur genau dann, sobald sich wirklich Daten geändert haben. Da ist nichts Obskures.
 
Nur ist die Auslösung von Events in einem ständig rechnendem Thread insofern schwierig, dass der Thread nichts über die Reaktionsfreudigkeit der Oberfläche weiß bzw. wissen solle.

Mit obskur bezog ich mich auf so Sachen wie z.B. jede 100. Änderung rausgeben oder ständig die Zeit abzufragen. Ersteres erwischt in 99% der Fälle ein für den Benutzer unzumutbares Timing bzw. miserable Performance, weil zu viele Aktualisierungen rausgegeben werden. Zweiteres ist ebenfalls vom Timing her schlecht, weil der Thread überhaupt innerhalb des Zeitfensters so oft an dieser Stelle vorbeikommen muss und zum anderen, weil es ein Systemaufruf ist, der je nach Plattform mal fix die Zeitscheibe des rechnenden Threads beendet.

Natürlich kann man ein Datenmodell innerhalb des Hauptthreads bauen, dass die Events über Änderungen, inklusive einer Kopie der Daten timinggesteuert weitergibt. Die Kernproblematik darüber darf man aufgrund eines anderen Designs trotzdem nicht vergessen.
 
Zurück
Oben