Zitat:

Was aber wenn der User das Fester bereits wieder geschlossen hat?

Einfach: Am Anfang im Queue nochmal prüfen, ob das Fenster noch da ist (z.B. über Screen.Forms das Self prüfen), bevor darauf zugegriffen wird.
Während des Queue kann das Fenster dann anschließend nicht mehr verschwinden. (außer man hat ein Application.ProgressMessage, einen Dialog oder Ähnliches darin)


Bei Dateioperationen auf eine Netzwerkfreigabe, da kann es auch schonmal ewig hängen.
Da kann man entweder Asynchron arbeiten, oder auch von außerhalb via CancelIo abbrechen.

Auch viele Netwerkkomponenten und auch DB-Komponenten haben eine Funktion um von außerhalb Operationen in einem anderen Thread abzubrechen.


Falls es keinen Timeout gibt, oder der nicht immer funktioniert, kann man z.B. beim Schließen des Fensters dennoch einen Abbruch einleiten.
Den Thread selbst aber hart abzuschießen (TerminateThread) ist aber niemals eine Lösung, denn wenn der z.B. grade dabei ist sich beim Speichermanager (FastMM) Seicher zu holen oder freizugeben und da grade in dem Moment eine CriticalSection gesperrt ist, kann man sich einen schönen Deadlock in anderen Threads einfangen.

Zitat von himitsu:

Einfach: Am Anfang im Queue nochmal prüfen, ob das Fenster noch da ist (z.B. über Screen.Forms das Self prüfen), bevor darauf zugegriffen wird.
Während des Queue kann das Fenster dann anschließend nicht mehr verschwinden. (außer man hat ein Application.ProgressMessage, einen Dialog oder Ähnliches darin)

Ja ok, man kann die Self Instance in der Forms-Liste (im queue) suche... Darüber habe ich in der Tat noch nicht nachgedacht... Nette Idee!
Weil ein Assigned(Self) geht logischerweise nicht.

Zitat von himitsu:

Falls es keinen Timeout gibt, oder der nicht immer funktioniert, kann man z.B. beim Schließen des Fensters dennoch einen Abbruch einleiten.

Wenn der Code im Execute zu 100% unter meiner Kontrolle ist - ok, dann kann ich auf Terminated abtesten. Das ist einfach.

Zitat von himitsu:

Den Thread selbst aber hart abzuschießen (TerminateThread) ist aber niemals eine Lösung

Genau, deshalb meine Lösung. Wenn ich das wirklich braucht, ist der Overhead klein und für die harten Fälle dann doch einen neuen Prozess erzeugen, der
sein eigenes Memory Management hat und ggf. den Thread killt und den Speicher aufräumt.

Mavarik