Danke, jetzt kann ich das wenigstens alles einschätzen.

schöne Feiertage
K-H

Egal was du machst, dieser Code sollte natürlich besser nur im Kontext des Hauptthreads (VCL) ausgeführt werden.


Für die Zukunft ist es so vorgesehen, daß Exceptions nicht auf der Klasse Exception bassieren müssen, sondern man da auch mal was Anderes einführen kann.

Zitat:

if GetCapture <> 0 then SendMessage(GetCapture, WM_CANCELMODE, 0, 0);

ReleaseCapture?

Zitat von himitsu:

Egal was du machst, dieser Code sollte natürlich besser nur im Kontext des Hauptthreads (VCL) ausgeführt werden.

Wird er ja. Die betreffende Methode wird über Synchronize aufgerufen.

Zitat von p80286:

ich meine mich zu erinnern, das eine Exception die Möglichkeit ist, ohne auf irgendetwas Rücksicht nehmen zu müssen, den Benutzer zu informieren. Gut ist etwas platt formuliert, aber von der Tendenz her richtig?

Nein, Exceptions sind ein Fehlerbehandlungsmechanismus (um zum Beispiel die leicht zu ignorierenden Rückgabewerte abzulösen).
Hier ist das etwas etwas genauer auseinander genommen: Exceptions sind für den Entwickler

Um auf das Ausgangsproblem einzugehen: Da Threads ein unabhängiger Kontrollfluss sind, wo würdest du die Exception denn auslösen? Im Hauptthread (wann)?
Für Sachen wie Fork-Join-Parallelismus gibt es sinnvolle Lösungen, aber für allgemein nutzbare Threads sieht es da düster aus.

Sicherheitshalber erwähnt, so einzeln dastehend ist das nicht erkennbar.

Per Synchronize kann man es nicht anzeigen, denn wenn es knallt, während der Hauptthread hängt, hängt auch die Ausgabe der Exception.
TThread.Queue und dann verzögert anzeigen, wäre da die einzige sichere Lösung, mit den Hausmitteln vom Delphi.