Also der Titel ist echt etwas verwirrend.
Nein, man nutzt die
VCL niemals nie innerhalb eines "anderen" Threads, als dem Hauptthread.
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.