MessageDLG - Endlos Loop in Thread

[alf.krause]

Hallo,

ich habe seit kurzem das Problem, dass fast immer (ca. 98% Schlechtfälle) die MessageDlg's aus einem Datenmodule nicht angezeigt werden und die App Endlos "leiert" in einem Thread, wo der Debugger nicht mehr viel sagt. Der Dialog ist nicht sichtbar und es kreiselt. Debugger siehe Anhang

Delphi 12.1 Patch 1 - VcL Anwendung

1) App hat Eurekalog (7.12.5 Stable)alf, das erkennt und meldet nichts. Loop Dedection Aktiviert -ohne Erfolg, Eurekalog deaktiviert -> ohne Erfolg, Thread Überwachung aktiviert -> ohne Erfolg

2) MessageDlg über MessageBox realisiert (https://www.delphipraxis.net/175592-...-sichtbar.html) ohne Erfolg

3) die vorhandenen TopMost Fenster mal deaktiviert und geschlosssen -> ohne Erfolg

4) Application.NormalizeTopMosts vor dem MessageDlg -> ohne Erfolg

5) QUEST_PRINTAUSGLECHSRECH direkt als Text übergeben -> ohne Erfolg

Das Ganze lief schon mal bzw. sehr lange und jetzt nicht mehr. An anderer Stelle wurde aber viel geändert, so das dass SVN keine wirkliche Option ist.


Beispiel:

if MessageDlg (QUEST_PRINTAUSGLECHSRECH,mtConfirmation,[mbYes,mbNo],0) = mrYes then
....

So eine Wirkliche Idee habe ich nicht mehr.

Hat jemand einen Tipp - Danke.

[himitsu]

Also der Titel ist echt etwas verwirrend.
Nein, man nutzt die VCL niemals nie innerhalb eines "anderen" Threads, als dem Hauptthread. :stupid:

Zitat:

MessageBox

Dann liegt es wohl nicht an den VCL-Dialogen.

MessageDlg nutzt standardmäßig intern die TaskDialog-API von Windows.
Unter gewissen Umständen (uraltes Windows, Idioten, VCL-Styles, sonstwas) werden intern aber VCL-Dialoge (TForm) genutzt.

Laufen bei dir Timer oder Threads, welche irgendwas machen/blockieren können?

Wie sieht die CPU-Last aus?
* hängt es nur (Sleep, WaitFor oder so)
* arbeitet irgendwas und der Thread arbeitet Volllast (Hauptthread mit 100%)

Joar, auf "Pause" im Debugger, während es im Dialog hängt
und falls man im Stack noch nichts sieht, dann versuchen mittels F7/F8 weiter zu schauen, ob man irgendwann in Code landet, welcher am Arbeiten ist/hängt.

Mal mit 32 Bit probieren?




Egal ob VCL-Dialoge oder DialogAPI vom Windows,
es läuft intern eine MessageLoop, welche alle Messages verarbeitet, also z.B. Timer und Paint der anderen Forms uvm.

Außer, dass die VCL-Dialoge TApplication.ProcessMessage nutzen und dort mehr machen,
als die "blanken" / fremden PeekMessage/TranslateMessage/DispatchMessage in der MessageLoop des Taskdialogs,
wo also WM_QUIT, OnMessage, IsPreProcessMessage, IsHintMsg, IsMDIMsg, IsKeyMsg und IsDlgMsg nicht behandelt würden, während der Dialog angezeigt wird.

[Kas Ob.]

@alf.krause,
Try to manually generate a report by EurekaLog for all running threads, this might help, you can call it manually or raise an exception, with EurekaLog settings set to pause all threads when generating a report.

Your screenshot showing a thread not the main thread and most likely that is OS one not even created by your application, open Threads while debugging with IDE.
Here a screenshot showing on the right what do you see (OS threads aka externals) and on the right the main thread, in your case there might be more, either yours or OS's:
Anhang 56958

Also you want to see if some API is in fact had executed and returned or not, so i suggest API monitor, there was a post explaining how to use it, and here what you might need to select
Anhang 56959

Hope that helps.

[alf.krause]

Das mit den Themes war dann der richtig Tipp. Hier hat er sich verhaspelt. Ich habe nochmal ein (weiteres Theme) rein genommen un dann wieder raus, jetzt geht es wieder korrekt.

[himitsu]

Das war vor Ewigkeiten schonmal ein Feature-Wunsch von mir und anderen,
dass Embarcadero endlich selbstständig den MainThread und am besten auch alle Execute der TThread-Nachfahren (System.Classes.ThreadProc) benahmt
und dass nach Jahrzehnten endlich Emba mal die neue ThreadName-API SetThreadDescription benutzt, anstatt oder zusätzlich zu diesen beschissenen NameExceptions.

Tipp: Als erste CodeZeile in der DPR oder zumindest als erste Zeile ins OnCreate der MainForm:

Delphi-Quellcode:

TThread.NameThreadForDebugging('MainThread');

und schon siehst du im Debugger (ThreadListe) direkt, welcher es ist.

[alf.krause]

Danke an alle