Ursache für hängende Applikation herausfinden

[Kas Ob.]

Hi,

First and foremost never ever ever ever use Application.ProcessMessages(); in background thread and anywhere in general !, nothing good will come from it, and will add more failure scenarios that no one can imagine or think of.

Now to this whole big thread, it is way more complex than it should be.

My suggestion for your case (the code above) to drop it all and replace it with something like the a thread that have one event (not two), single one will do the job perfectly, or even remove the event altogether and use simple Sleep or SleepEx with very short sleep time (interval) like 50ms (1/20 of second), check triggering condition and perform one of the following
1) Enabled / Disabled nothing need to be done, loop again.
2) Exit request, then exit.
3) Need to call or notify the main thread then use PostMessage (simple like that) and loop again.
4) You want more control over timing and intervals then use Sleep(1).
5) Access the conditions from the threads itself only using.

From the code i deduce you are using this only for Windows then hide this new small thread in small TWinControl (or an invisible form) or what ever you see fit, and implement the a Message handler for that Message coming form PostMessage, and that is it.

On side note : PostMessage will of course use a window message, and most importantly if for some reason the message queue is full or blocked (the messages are not being process for other defect or bugs) then Synchronize from a thread will not be helpful too and will only make finding the real bug/flaw harder, Synchronize will only waste your time finding the bug in almost every scenario were things went wrong.
Also if PostMessage doesn't work or fail then Synchronize will not help either.

[jaenicke]

Der Aufruf passierte laut Stacktrace 67 Zeilen weiter unten ab dem begin des Execute gezählt. Da ist im geposteten Quelltext ein end. Da müsstest du noch einmal schauen, was dort vorher stand.

Und wenn nun ohne ProcessMessages die Anwendung hängt... sieht der Bugreport noch genauso aus? Dein Timer nutzt ja nicht immer Synchronize. Kann es vorkommen, dass es ohne aufgrufen wird und dort etwas mit der VCL passiert?

Zitat von Bodenseematze:

Da es viele Aktionen abzuarbeiten gibt und das etwas länger dauert, verwende ich eine Mini-Form soz. als "Bitte Warten..."-Anzeige.
In dieser wird ein Anzeigetext gesetzt (ändert sich mit der aktuellen Aktion) und mit zu und abnehmenden "..." wird signalisiert, dass die Arbeit noch am Laufen ist.
Für dieses Zu- und Abnehmen habe ich eine eigene Klasse TTimerThread verwendet, die einen Thread basierten Timer zur Verfügung stellt bzw. stellen soll.

Wenn du im Hauptthread eine Aktion ausführst, kann auch ein Thread keine Aktualisierung der GUI durchführen. Dann bleibt Synchronize schlicht hängen, weil Synchronize voraussetzt, dass der Hauptthread auch funktionsfähig ist, sprich Nachrichten abarbeitet. Das Synchronize wird in WM_IDLE abgearbeitet. Wenn der Hauptthread beschäfitgt ist, passiert das nicht.

Nicht die Statusanzeige oder deren Steuerung gehören in den Thread sondern die lange dauernden Aktionen selbst.

Alternativ (aber nicht so schön) könntest du auch ein threadbasiertes Fenster anzeigen. Das kann auch direkt aus dem Thread ohne Synchonisierung verwendet werden. Ich habe dafür mal eine kleine Bibliothek angefangen:
https://github.com/jaenicke/MTCL
Da es dafür mittlerweile doch Interesse gibt, arbeite ich daran vielleicht doch mal weiter...