Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
VisualBasic Threading
- Ersteller mabstrei
- Erstellt am
H
Housechen
Gast
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.
Eine Endlosschleife für einen ganzen CPU-Kern sinnlos verbrennen.
olampl
Lt. Commander
- Registriert
- Aug. 2005
- Beiträge
- 1.691
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.
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.
olampl
Lt. Commander
- Registriert
- Aug. 2005
- Beiträge
- 1.691
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)
SheepShaver
Commodore
- Registriert
- Nov. 2004
- Beiträge
- 4.171
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.
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.
M
MacGyver
Gast
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
olampl
Lt. Commander
- Registriert
- Aug. 2005
- Beiträge
- 1.691
MacGyver schrieb:Mußt nur die Eigenschaft "CheckForIllegalCrossThreadCalls" der Control-Klasse auf false setzen
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
7H3 N4C3R
Lt. Commander
- Registriert
- Feb. 2002
- Beiträge
- 1.816
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.
H
Housechen
Gast
Leute ich wollte nur mal sagen, dass der Threadersteller sich seit der Eröffnung vor 4 Tagen sich nichtmehr gemeldet hat.
SheepShaver
Commodore
- Registriert
- Nov. 2004
- Beiträge
- 4.171
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.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.
7H3 N4C3R
Lt. Commander
- Registriert
- Feb. 2002
- Beiträge
- 1.816
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.
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.
Ähnliche Themen
- Antworten
- 13
- Aufrufe
- 1.229
- Antworten
- 10
- Aufrufe
- 687
- Antworten
- 5
- Aufrufe
- 547