Debugger langsam bei OpenDialog

[Andreas L.]

Hallo,
wenn ich ein Firemonkey-Projekt debugge in dem ein OpenDialog (oder SaveDialog) aufgerufen wird dauert es beim Aufruf von OpenDialog.Execute eine Ewigkeit bis der Dialog aufgeht. Und jeder Klick im Dialog lässt ihn eine Zeit lang einfrieren. Nach einem Klick auf Abbrechen oder Öffnen schließt sich der Dialog und der Debugger läuft mit ganz normaler Geschwindigkeit weiter.

Was kann ich dagegen machen? Gibt es irgendeine Debugger-Option die da abhilfe schafft? Wie kann das überhaupt zu Stande kommen? Ist der Dialog nicht letztendlich nur eine WinApi-Funktion die gar nicht debuggt werden kann oder muss?

[jaenicke]

Leider klinken sich da viele Tools ein, die nicht immer sauber entwickelt wurden. Zum Beispiel gab es vor ein paar Jahren einmal den Fall, dass Teamviewer (ich glaube Version 6) dabei einen Absturz beim Debuggen verursacht hat.

Welches Tool das sein kann, kannst du evtl. im Ereignislog während des Debuggens sehen, wenn du dort siehst, dass DLLs geladen werden. Allgemein lässt sich das nicht beantworten.

[himitsu]

Wie dir im Debugger bestimmt auffällt, werden da auch viele DLLs eladen und anschließend fast alle auch wieder entladen.

Hier kann mam notfalls Welche vorher manuell laden, damit sie dann schon da sind.

[Der schöne Günther]

Ich bin von 10.0 Seattle auf 10.4 Sydney umgestiegen - Unter Seattle waren diese Dialoge (mit den vielen Shell-DLLs) wirklich der Horror wenn es im Debugger lief, unter 10.4 kommt es mir sehr viel schneller vor. Allerdings ist auch die Windows-Version neuer, vielleicht werden hier mittlerweile weniger DLLS ge/entladen.

[Bernhard Geyer]

Zitat:

Zitat von Der schöne Günther (Beitrag 1469432)

Ich bin von 10.0 Seattle auf 10.4 Sydney umgestiegen - Unter Seattle waren diese Dialoge (mit den vielen Shell-DLLs) wirklich der Horror wenn es im Debugger lief, unter 10.4 kommt es mir sehr viel schneller vor. Allerdings ist auch die Windows-Version neuer, vielleicht werden hier mittlerweile weniger DLLS ge/entladen.

Hatten mit XE6 auch Problem mit dem Dialog Probleme wegen Warte/Ladezeiten
Jetzt mit 10.2 und neuen Rechner nicht mehr.

Ich würde her nach jaenicke gehen.
Da sind wohl zu viele Systemerweiterungen installiert.
Evtl. auch einige veraltete.

[Andreas L.]

Danke für die vielen Antworten.

Ich habe in das Debug-Log geschaut welche DLLs geladen werden. Aber diese Log hat 8000 Zeilen... Beim überfliegen habe ich nichts gefunden. Könnt ihr mir ein kostenloses Tool empfehlen mit dem ich diese Log analysieren kann? Oder hat Delphi so eine Funktion? Ein einfacher Filter würde schon viel bringen...

Was ich sicher sagen kann ist das kein Viren-Scanner sich in den Prozess/Debugger einklinkt. Auch den genannten TeamViewer habe ich nicht laufen. Allerdings habe ich eine Shell-Erweiterung installiert die im Explorer die Thumbnails von Grafik-Formaten anzeigt die Windows nicht von selbst unterstützt. Die Erweiterungen heißen SageThumbs und WebP-Decoder. Habt ihr Erfahrungen damit?

Das Phänomen tritt übrigens nicht nur bei Firemonkey sondern auch bei VCL-Projekten auf.

[Der schöne Günther]

Wenn du das öfter brauchst würde ich mir überlegen

1. den Debugger für den Zeitpunkt auszuklinken und danach wieder mit der laufenden .exe zu verbinden
2. Die für Tests den Pfad hart einzukodieren und somit den "Datei öffnen"-Dialog zu überspringen. Oder dir notfalls einen billigen eigenen Testdialog zum Öffnen zu bauen.

[BerndS]

Ich hatte so was in der Art im DEBUG-Modus der Anwendung bei der Verwendung der ERIC-31 DLLs (E-Bilanz).
Das setzen der Systemvariable _NO_DEBUG_HEAP=1 hat das Problem behoben und alles ging wieder sehr schnell.
Möglicherweise hilft das ja.

[Andreas L.]

Zitat:

Zitat von Der schöne Günther (Beitrag 1469457)

den Debugger für den Zeitpunkt auszuklinken und danach wieder mit der laufenden .exe zu verbinden

Wie genau mach ich das?

Zitat:

Zitat von Der schöne Günther (Beitrag 1469457)

Die für Tests den Pfad hart einzukodieren und somit den "Datei öffnen"-Dialog zu überspringen. Oder dir notfalls einen billigen eigenen Testdialog zum Öffnen zu bauen.

Das mache ich bereits. Ist aber trotzdem blöd wenn man mehrere Dateien öffnen muss.

Zitat:

Zitat von BerndS (Beitrag 1469460)

Ich hatte so was in der Art im DEBUG-Modus der Anwendung bei der Verwendung der ERIC-31 DLLs (E-Bilanz).
Das setzen der Systemvariable _NO_DEBUG_HEAP=1 hat das Problem behoben und alles ging wieder sehr schnell.
Möglicherweise hilft das ja.

Soll diese Variable einfach in die Umgebungsvariablen von Windows rein?

[jaenicke]

Zitat:

Zitat von Andreas L. (Beitrag 1469498)

Zitat:

Zitat von Der schöne Günther (Beitrag 1469457)

den Debugger für den Zeitpunkt auszuklinken und danach wieder mit der laufenden .exe zu verbinden

Wie genau mach ich das?

Start --> Vom Programm trennen
Start --> Mit Prozess verbinden...