Dateidialog im Debug-Mode: nervende Verzögerung

[Perlsau]

Moin allerseits

Wenn ich im Debug-Mode meines Delphi2009 einen Dateidialog (TOpenDialog) mit Execute öffne, dauert es teilweise bis zu einer Minute, bis ich dort eine Datei auswählen kann. Mir leuchtet zwar ein, daß der Delphi-Debugger auch den Dateidialog, der ja lediglich eine Methode der Win-API kapselt, analysiert, aber das nervt total. Gibt es eine Möglichkeit, Dateidialoge vom Debuggen auszunehmen?

[himitsu]

Du kannst im Log dir merken welche DLLs geladen werden und baust dir in den Programmstart ein LoadLibrary ein, wo du diese schonmal vorlädst. (zumindestens die Wichtigsten davon)

Den Programmstart kann man beschleunigen, indem man nicht sofort losdebuggt (F9), sondern das Programm startet und sich erst dann zum Prozess verbindet, wenn es nötig ist. (Strg+Shift+F9 und Start > Mit Prozess verbinden)

[Perlsau]

Zitat von himitsu:

Du kannst im Log dir merken welche DLLs geladen werden und baust dir in den Programmstart ein LoadLibrary ein, wo du diese schonmal vorlädst. (zumindestens die Wichtigsten davon)

Welche DLLs? Ich lade doch gar keine DLLs im Programm
Achso, du meinst die DLLs, die der OpenDialog benötigt, machen die Verzögerung aus? Müßte es dann nicht beim zweiten Aufruf von OpenDialog schneller gehen, wenn die DLLs vom ersten Aufruf bereits geladen wurden? Oder werden die gleich danach wieder entladen? Ich probier das mal mit dem LoadLibrary ...

Zitat von himitsu:

Den Programmstart kann man beschleunigen, indem man nicht sofort losdebuggt (F9), sondern das Programm startet und sich erst dann zum Prozess verbindet, wenn es nötig ist. (Strg+Shift+F9 und Start > Mit Prozess verbinden)

Das hab ich eben ausprobiert. Tatsächlich geht der OpenDialog nun ganz flott, aber: Wenn ich vor dem Programmende "mit Prozess verbinden" klicke, erscheint das CPU-Fenster, mit dem ich absolut nichts anzufangen weiß – hab nunmal keine Ahnung von Assembler (mehr). Der Prozeß, mit dem ich verbinden soll, ist doch mein laufendes Testprogramm, nicht wahr?

(Da will ich debuggen, weil ich da irgendwo eine Schutzverletzung und MemoryLeaks auslöse – siehe auch dort, wo ich gerade ein Problem von Delbor nachstelle und zu lösen verusche.)

[himitsu]

Siehe Ereignislog ... viele der DLLs werden danach gleich wieder entladen.
Und beim Laden sucht und läd der Debugger auch noch die Debuginfos der DLLs ... das bremst schon ein bissl.


Mit Prozess verbinden:

• Den Haken bei "Pause nach Verbindung" entfernen
• und dann muß nur irgenwo ein Haltepunkt sein, welcher danach das Programm geziehl anhält ... es geht auch F4 (Bis Cursorposition ausführen) und dann warten, bis das Programm dort vorbei kommt.

[Perlsau]

Zitat von himitsu:

Siehe Ereignislog ... viele der DLLs werden danach gleich wieder entladen.
Und beim Laden sucht und läd der Debugger auch noch die Debuginfos der DLLs ... das bremst schon ein bissl.

Das konnte ich auch beobachten und wußte dann nicht, welche DLLs ich laden sollte. Hab's verworfen ...

Zitat von himitsu:

Mit Prozess verbinden:

• Den Haken bei "Pause nach Verbindung" entfernen
• und dann muß nur irgenwo ein Haltepunkt sein, welcher danach das Programm geziehl anhält ... es geht auch F4 (Bis Cursorposition ausführen) und dann warten, bis das Programm dort vorbei kommt.

Das funktioniert einwandfrei
Wieder was dazugelernt – hab Dank, Himitsu

[himitsu]

Ach, einfach aus dem Log das Entladen danach kopieren (alternativ geht auch das Laden davor) und den Text um die Dateinamen durch LoadLibrary(´ und ´); ersetzen lassen.

PS: if IsDebuggerPresent then