Hallo.

Ich hätte mal eine Frage wie ich einen Thread so gestalten kann,
dass ich ihn beenden kann ohne das irgendwelche Fehler entstehen.

Ich hab schon einiges ausprobiert und die Boardsuche genutzt,

auf If Thread Is Nothing AndAlso Not Thread.IsAlive geprüft doch selbst da kamen Nullreferenceexceptions.

Kennt jemand eine saubere Methode um Threads vernünftig zu starten und beenden?

Hi
der Test führt normalerweise IMMER zu einer Null-Reference-Exception, da überprüft wird, ob die Referenz Nothing ist, falls sie Nothing ist, soll IsAlive überprüft werden. Einen Thread beendet man per Verlassen der Prozedur, die vom Delegaten aufgerufen wird und auch nicht per Abort.

Gruß
~blaze~

Das was du machst ist ein komplett falscher Ansatz.
Du machst in deinem Delegat eine Abbruchbedingung. Wenn diese zutrifft beendet sich der Thread von selbst in dem er z.B. eine Schleife verlässt.
Damit du das auch sync hinbekommst und du auch weißt, dass er nun beendet ist machst du noch Join.
In der Praxis heißt das:

Wie sieht das mit asynchronen Actions aus?

Hab jetzt mal folgendes probiert:



Was würde mir ein Thread da für vorteile bieten bzw. wann nutze ich einen Thread und wann sowas?

Mit dieser Methode erspart man sich ja auch das Invoken oder?

Was heißt erspart man sich Invoken? a) machst dort nix anderes als ein Invoke und b) ist das BeginInvoke nicht wirklich async. Es steht dort aber hatte kürzlich das mal in WPF ausprobiert und ich nehme an in WinForms ist es nicht anders. Habe aus einem anderen Thread BeginInvoke aufgerufen, war aber nicht async. Außerdem wenn du Invoke mit einem neuen Thread ersetzt, erzielst du so oder so genau das Gegenteil zu einem Invoke.

Wie soll ich das denn am besten lösen in diesem Fall?

Na was willst du denn nun erreichen?
Erst gings darum nen Thread zu beenden jetzt kommst du mit Invoke?

Mir gehts darum den Code so auszuführen, dass die Form nicht hängt und man derweil auch andere Aktionen ausführen kann.

theFiloe irrt, wenner meint, mit .BeginInvoke sei das nicht async.ist eine saubere Verlagerung des D - Aufrufes in einen aus dem Threadpool genommenen NebenThread.

Den weiteren Code habich nicht verfolgt, Bitte VB-Tag benutzen - aber richtig

Hi
die meisten Control-Operationen erfordern allerdings bei Aufrufen aus dem anderen Thread Callbacks, um die Abfolge der Message-Queue nicht durcheinander zu bringen. Beim Invoken sollte der Callback einfach in die Queue eingereiht werden. BeginInvoke auf Forms sollte asynchron, aber im Thread der Form laufen (also asynchron zum aufrufenden Thread), da nicht auf die Beendigung des Aufrufs gewartet wird. Da allerdings auf dem Delegat BeginInvoke ausgeführt wird, sollte das, sofern der Check aktiviert wurde, zu einem Fehler führen oder habe ich da was übersehen? (die Listenveränderungen sollten doch eigentlich ebenfalls im GUI-Thread ablaufen oder?)

Gruß
~blaze~

Wie realisiere ich das denn jetzt möglichst gut?

Dass ich auf Controls zugreife ist nunmal so.

Benutze ich jetzt Me.Invoke(Sub() gar nicht?

Nur mit Control.BeginInvoke? Oder doch Threads?

Lade halt erst die Daten asynchron und zum füge sie erst zum Schluss alle auf einmal in die Liste ein oder so (am besten per AddRange oder BeginUpdate + EndUpdate oder wie die heißen). Wobei das dann auch nicht unbedingt auf einen Thread zurückgreifen muss. Wenn das zu lange dauert puffere halt einfach immer solange, bis ein bestimmter Zeitrahmen überschritten wurde und update danach die darstellende Liste per Invoke. Es macht auf jeden Fall keinen Sinn, ständig per Invoke die Informationen zu updaten. Das braucht dann länger und blockiert oftmals auch die Benutzerinteraktionen.

Gruß
~blaze~

Kevin Hombre schrieb:

vernünftig zu ... beenden?

Ein Thread sollte sich immer selbst beenden, wenn er seine Arbeit getan hat.
Dazu muss das Programm lediglich die Thread-Start-Prozedur verlassen.
Einen Thread mit dem Abort-Holzhammer zu beenden sollte außergewöhnlichen Situationen vorbehalten sein, z.B. einem ungewollten Programmabbruch.

Jo, nur selbst dann sollte man ggf. noch mal überprüfen, dass das Programm alles in einem gesicherten Zustand hinterlässt. Es ist eher unpraktisch, wenn das Programm fliegt und einfach mal grad paar Dateien halb fertig sind o.Ä., obwohl dieser Teil ziemlich sicher noch funktioniert hätte. Kommt halt auf den Verwendungszweck an.

Gruß
~blaze~