Ursache für hängende Applikation herausfinden

[Bodenseematze]

Zitat von 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.

Im geposteten Quellcode wurden die Aufrufe für mein Logging entfernt - deswegen die Diskrepanz.

Das wäre dann die Zeile

Delphi-Quellcode:

                        // Methode direkt aufrufen:
                        try
-->                           _evTimerFunc( Self );
                        except

Zitat von jaenicke:

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?

es ist auch aktuell die o.a. Zeile...

Zitat von jaenicke:

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

Da gebe ich Dir prinzipiell schon recht, aber das ist auch nicht so einfach.
Da werden externe Prozesse gestartet, Dateien mehrmals hin und her kopiert und angepasst, Reportdaten aktualisiert, eine Paradox-Tabelle mit Daten befüllt und andere Dinge...
...der Ablauf war ursprünglich nicht so aufwändig - es ist aber mit der Zeit immer mehr geworden und jetzt merkt man eben, dass es eine deutlich Verzögerung im Ablauf gibt.

Deswegen der Gedanke mit dem "Bitte warten..."-Dialog, in dem auch die aktuell ausgeführte Aktion textuell angezeigt werden soll.
Da in der ursprünglichen Version der angezeigte Text nicht aktualisiert wurde (bzw. die Aktualisierung nicht angezeigt wurde, hatte ich den Gedanken mit dem Thread, der den Text im Dialog animiert und refresht.

Zitat von jaenicke:

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.

Das würde erklären, warum die Dialoganzeige nicht aktualisiert wird...

Zitat von jaenicke:

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.

Wenn es da einen "einfachen" Dialog gäbe, dessen Text selber aktualisiert, wäre das nicht schlecht!

Zitat von jaenicke:

https://github.com/jaenicke/MTCL
Da es dafür mittlerweile doch Interesse gibt, arbeite ich daran vielleicht doch mal weiter...

Ich schaue mir die mal an, vielleicht kann ich da was raus extrahieren...

Zitat von peterbelow:

Nur noch was am Rande: MsgWait.. macht innerhalb eines sekundären Threads keinen Sinn da ein solcher Thread keine message queue hat! Er wird also niemals eine input-message (QS_ALLINPUT) bekommen, alle vom Benutzer generierten Messages (mouse, keyboard) landen in der Queue des main threads und der sekundäre thread sieht sie nicht.

Ich sehe schon, ich werde diese Klasse komplett wegschmeissen müssen - die macht so keinen Sinn...

Zitat von Kas Ob.:

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

Thanks a lot for your help / suggestions.
But I'm not sure if I understand everything you mentioned.
Maybe you have some example code for it?

So actually I need a dialog who shows some progress messages - the thread should be able to set the text on that dialog (or the whole dialog is the thread) to show the progress even when the main thread is busy...

EDIT: BTW, the dialog itself could also be a generated native windows dialog - it must not be Delphi at all