Zitat von Delphi-Laie:

nur insoweit, als daß die Fehlermeldung zwar auch kommt, wenn die Bedingungen dafür gegeben sind, jedoch danach das Programm dennoch mit einer Fehlermeldung ("Exception") abstürzt.

Welche Exception kommt denn genau?

Zitat von Uwe Raabe:

Zitat von Delphi-Laie:

nur insoweit, als daß die Fehlermeldung zwar auch kommt, wenn die Bedingungen dafür gegeben sind, jedoch danach das Programm dennoch mit einer Fehlermeldung ("Exception") abstürzt.

Welche Exception kommt denn genau?

Siehe Anhang.

Sie kommt nach meiner selbstprogrammierten Fehlermeldung, und danach ist mit dem Programm Ende.

Wie gesagt, als alles im VCL-Thread lief, lief es wie gewünscht.

Die Excepion hat eine andere Ursache. Überprüfe mal, ob die im Fehlerfall nicht doch irgendwelche Variablen verwendest, die dann noch nicht oder nicht mehr da sind. Immerhin wird der Code im Thread nicht vollständig durchlaufen, sondern mittendrin durch die Exception abgebrochen.

Wenn du mehr wissen willst, musst du mehr Code liefern.

Zitat von Uwe Raabe:

Die Excepion hat eine andere Ursache.

Eine andere Ursache als was?

Zitat von Uwe Raabe:

Überprüfe mal, ob die im Fehlerfall nicht doch irgendwelche Variablen verwendest, die dann noch nicht oder nicht mehr da sind.

Mit Sicherheit kann etwas nicht (richtig) konvertiert werden, das war mir gleich klar, aber dafür ist try..except schließlich da und funktionerte doch vorher auch.

Zitat von Uwe Raabe:

Immerhin wird der Code im Thread nicht vollständig durchlaufen, sondern mittendrin durch die Exception abgebrochen.

Ja, aber genau dafür, um so etwas abzufangen, ist schließlich doch try..except da (jetzt wiederhole ich mich allmählich)?! Wie kann ein und derselbe Code in einem Thread eine exception auslösen, im anderen Code, der im VCL-Thread läuft, die exception abgefangen werden? Leuchtet mir nicht ein.

Zitat von Uwe Raabe:

Wenn du mehr wissen willst, musst du mehr Code liefern.

Das ist leider nicht so einfach, denn es spielen mehrere Routinen und Deklarationen aus mehreren Units mit. Aber wenigstens scheint sich auch Nicht-VCL-Thread-Code im Quelltext via Debugger schrittweise nachverfolgen zu lassen.

Danke an Dich erstmal für Dein Bemühen!

So, ich bin ein Stück weiter.

Schuld ist nicht irgendeine der externe Berechnungsfunktionen aus einer externen Unit, sondern - als Argument dafür - eine schnöde Typkonvertierung (prinzipieller Quellcode):

markieren

Delphi-Quellcode:

try
strtoint([String(variable)])
except

, wobei der String, als Integerzahl gedacht, größer als der größtmögliche Wert der Integervariablen ist (der String könnte genausogut ungültige Zeichen enthalten, gerade ausprobiert).

Außerhalb des VCL-Threads funktioniert try..except offenbar nur eingeschränkt: Except wird zwar aufgerufen, die Exception jedoch nicht abgefangen.

Fehler gefunden: Es lag am Aufruf einer anderen Prozedur, die immer, also auch nach dem try..except, aufgerufen wurde. (Ermitteln der Systemzeit, jedenfalls ist der zentrale Befehl in jener Prozedur QueryPerformanceCounter. Das passiert, um die Rechendauer zu ermitteln.)

Mit dem nur noch optionalem Aufruf der Prozedur (nicht, wenn except aufgerufen wird, dann wird eine boolesche Variable auf false gesetzt, was den späteren Aufruf verhindert) ist der Programmabbruch vermeidbar.

Dieses Programmverhalten leuchtet mir nicht ein und stellte im VCL-Thread auch kein Problem dar.

Danke noch einmal, Uwe!

Ergänzung: Ganz so sauber, wie dargestellt, lief es auch im VCL-Thread doch nicht ab: Nach der programmierten Fehlermeldung kam auch noch eine exception hinterher, aber das Programm stürzte nicht ab (indem es aus dem Speicher verschwand), sondern ließ sich nach dem "Wegklicken" letzter weiterbenutzen.

Dann verhält sich aber nicht try..except anders, sondern der Fehler in deinem Code hat in einem anderen Thread schwerwiegendere Auswirkungen. Er sollte jedenfalls in beiden gefixed werden

Ich bin auch kein großer Fan von ShowMessage in Threads. Ich mir angewöhnt um die Execute-Methode immer komplett(!) noch einen try..except zu bauen, in dessen execpt-Teil in ein Logfile oder eine Tabelle protokolliert wird. Zusätzlich zu den in dieser aufgerufenen Methoden, die ggf. selbst auch loggen um Fehler genauer eingrenzen zu können. Gerade wenn mehrere Threads rege miteinander interagieren vermeidet man so ggf. falsche Folgefehler, die dadurch kommen, dass andere Threads auf den dann angehaltenen warten während er synced die Meldung anzeigt.