Hallo,
Ich wollte nur mal eine Allgemeine Frage stellen und zwar :
Was arbeitet zuverlässiger / stabiler ein Timer oder ein Thread mit Checkforillegalcrossthreadcalls = false ?



Mfg Kevin.

Delegates

Um Tsuyos Antwort etwas auszuführen:
Setze niemals CheckForIllegalCrossThreadCalls auf False! Nimm Delegates.
Ich würde sagen, dass ein Thread zuverlässiger ist. Auf jeden Fall dann, wenn du Dinge tust, die nicht im UI-Thread laufen müssen. Zugriffe auf das UI müssen bei Threading über Delegates und BeginInvoke() durchgeführt werden.

Viele Grüße, Phil.

Gutelaunetyp schrieb:

Was arbeitet zuverlässiger / stabiler ein Timer oder ein Thread mit Checkforillegalcrossthreadcalls = false ?

Weder, noch. Wenn du Multithreading verwendest und auf Controls aus einem anderen Thread zugreifen musst, brauchst du einen Wrapper für den entsprechenden Aufruf, der dir die Daten an den richtigen Thread marshallt. CheckForIllegalCrossThreadCalls hat seine Berechtigung und sollte IMMER True sein, da es bei unerlaubten direkten Zugriffen leicht zu Deadlocks kommt, die deine Anwendung unbedienbar machen. Ein Timer ist sowieso keine Lösung für den Zweck, den die meisten User hier erreichen wollen. In diesem Zusammenhang möchte ich auch noch loswerden, dass du von Application.DoEvents() Abstand nehmen solltest. Der angesprochene Wrapper ist beim Multithreading die einzige vernünftige Lösung.

besser als Delegates finde ich jedoch PostAsyncs :P(damit arbeitet auch der BackgroundWorker, damit z.B. das ProgressChanged Event wieder im GUI Thread ausgeführt wird...)

Könntest du mal ein Link oder Beispiel für PostAsync zeigen. Ich dachte sowas wie das Progresschanged event ginge über DynamicInvokes..

irgendwer hat da mal ein(fast Fehlerfreies - musste einfach ein paar Fehler rein machen) Bsp. gepostet: [VB.NET] Form-Anwendung laufen lassen, bis anderer Prozess beendet wird

jvbsl schrieb:

PostAsyncs

Du meinst damit wohl ein PostMessage mit dem entsprechenden Thread als Ziel, oder? Das Codebeispiel, das im vorigen Post verlinkt wird, zielt auf ein ganz anderes Thema ab (und ist dazu, wenn ich das sagen darf, nicht gerade die beste Lösung auch für die dortige Frage; eher quick&dirty). Im Entfernten hängt das natürlich alles voneinander ab - aber dafür muss einfach das Hintergrundwissen vorhanden sein, wovon wir (@jvbsl) nicht ausgehen sollten.

Weitere Informationen dazu gibts in diesem Thread (inkl. der dort weiterverlinkten Seiten): social.msdn.microsoft.com/foru…6-4b4d-a2e0-3948e256b899/

ja ich meine PostMessage und Async meint ich aufgrund von den Threads, weil es dann ja auch Asynchron ist...
quick&dirty kommt stark darauf an, PostMessage ist sehr wohl sauber, aber die Lösung mit ner endlosschleife in einem Thread ist wohl eher hier das Problem
Aber hier war das sehr wohl angebracht, bei einem Invoke wird ja darauf gewartet, bis die entsprechende Methode ausgeführt wurde(Lösung, dass der Thread nicht wartet->BeginInvoke oder PostMessage ;))

jvbsl schrieb:

aber die Lösung mit ner endlosschleife in einem Thread ist wohl eher hier das Problem

...der Thread selbst ist das Problem - er hält die Anwendung im Hintergrund aktiv, welche aber keinerlei Eingaben verarbeiten kann, da sich der Thread in einer Endlosschleife befindet. Besser wäre in diese Fall Application.Run() ohne Parameter, damit der Prozess mit Application.Exit() oder extern sauber beendet werden kann.

PostMessage ist hier schon angebracht - aber warum so umständlich? Control.BeginInvoke() verwendet diese Funktion intern - das muss nicht selbst implementiert werden.

das sollte doch in einem extra Thread sein?!^^ Und meinem Code zufolge wird das Application.Exit ebenfalls aufgerufen und somit sauber beendet...

PostMessage ist hier schon angebracht - aber warum so umständlich? Control.BeginInvoke() verwendet diese Funktion intern - das muss nicht selbst implementiert werden.

Da man Threads oft auch in Klassen verwendet und dort will man evtl. auch ein Event im GUI Thread aufrufen, dies geht aus einer Klasse ohne das externe Control nicht mit Invoke

Doch das geht mit Invoke ebenso!

doch nicht aus einer Klasse heraus?(nat. ohne ein Control gegeben zu haben), wenn es geht dann bin ich bereit zu lernen(wäre über ein Beispiel froh ;))

HI, ich habe vor einiger Zeit danach gesucht und damals etwas gefunden. Es war ähnlich aufgebaut wie ich das jetzt hier habe.
Leider habe ich den Link zu dieser Quelle nicht mehr. Lediglich den gefundenen und von mir etwas bearbeiteten Code den ich damals eingesetzt hatte:
Ich habe im Beispiel auf Custom Event Args verzichtet.


Klasse:



Beispielanwendung:

hui schon wieder was gelernt ;), aber mit einem PostMessage ist das noch wesentlich kürzer, was jetzt davon besser ist kann ich selbst nicht beurteilen, aber wenn PostMessage beim BackgroundWorker verwendet wird, glaube ich nicht, dass es Falsch, bzw. schlecht ist...Was nun besser ist, müsste man wohl irgendwie mal bewerten