TForm schließen dauert lange

[backdraft]

Hallo zusammen,

ich habe eine Form, die dauert ca. 10 Sekunden, bis sie geschlossen wird.
Auf der Maske sind sehr viele Komponenten, mit Frames die geschachtelt sind.

Gibt es eine einfache Möglichkeit zu erkennen welcher Destroy lange dauert?

LG
Oliver

[jaenicke]

Du brauchst doch nur das Programm im Debugger starten und dann in der Wartezeit auf Pause zu drücken. Dann schaust du nach, was der erste Thread in der Liste gerade tut. Das musst du ggf. ein paarmal wiederholen, falls das nicht gleich eindeutig ist.

Viele Komponenten heißt aber auch viele Benachrichtigungen usw., die da geschickt werden. Das kann schon dauern.

[backdraft]

Zitat:

Zitat von jaenicke (Beitrag 1520330)

Du brauchst doch nur das Programm im Debugger starten und dann in der Wartezeit auf Pause zu drücken. Dann schaust du nach, was der erste Thread in der Liste gerade tut. Das musst du ggf. ein paarmal wiederholen, falls das nicht gleich eindeutig ist.

Viele Komponenten heißt aber auch viele Benachrichtigungen usw., die da geschickt werden. Das kann schon dauern.

Hab ich schon probiert, ich lande immer wieder woanders, weil so viele Threads laufen :-(

Mein Idee wäre eher sowas wie sich in den TComponent.Destroy zu hängen.
Und dann quasi Zeit merken, inherited Destroy aufrufen, Dauer berechnen, ausgeben.
Ich meine mich auch zu entsinnen, dass ich mal irgendwo über einen solchen Code gestolpert bin, wie man sich in eine Methode hängt.
Leider finde ich nichts passendes bei Google.

[blawen]

Verwendest Du zufälligerweise TMS-Komponenten auf der Form?

[backdraft]

Zitat:

Zitat von blawen (Beitrag 1520334)

Verwendest Du zufälligerweise TMS-Komponenten auf der Form?

Nein, ich denke es kommt vom ActiveQueryBuilder.
Sonst sind es nur DevExpress Sachen.

[backdraft]

Habs wiedergefunden...

https://github.com/MahdiSafsafi/DDetours

[jaenicke]

Zitat:

Zitat von backdraft (Beitrag 1520331)

Hab ich schon probiert, ich lande immer wieder woanders, weil so viele Threads laufen :-(

Andere Threads haben damit aber nichts zu tun. Hast du auch wirklich den Hauptthread angeschaut?

Wenn du auf Pause gehst und das Programm wirklich beim Entladen des Formulars ist, dann musst du dort auch landen. Vielleicht ist es nicht gleich die Stelle, die lange dauert, aber dort landen musst du. Kannst du von dem Stacktrace einfach einmal einen Screenshot posten?

[himitsu]

Mal AQTime oder Ähnliches benutzen?

Nee, man landet nicht immer automatisch im Hauptthread :(,
aber ins FormCreate, oder besser noch als eine der ersten Zeilen, vor

Delphi-Quellcode:

Application.Run;

, in die DPR:

Delphi-Quellcode:

TThread.NameThreadForDebugging('MainThread');

Und endlich mal Emba beibringen, dass es von Haus aus ins Programm gehört (direkt in die Initialisierung der RTL)
und dass sie endlich mal, nach vielen vielen vielen Jahren, die neue API von Windows benutzten sollen,
denn deren eigener Dreck arbeitet mit einer stillen Exception und wenn man den Debugger erst später anhängt, dann weiß der Debugger nichts von diesem Namen.

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1520343)

Nee, man landet nicht immer automatisch im Hauptthread :(,
aber ins FormCreate, oder besser noch als eine der ersten Zeilen, vor

Delphi-Quellcode:

Application.Run;

, in die DPR:

Delphi-Quellcode:

TThread.NameThreadForDebugging('MainThread');

Ich hatte noch nie den Fall, dass der Hauptthread nicht als erstes in der Threadliste aufgetaucht ist.

[himitsu]

Ich schon einige Male, aber häufiger dann, wenn man sich nachträglich mit dem Debugger anhängt.