Open und Savedialoge zu langsam

[hanspeter]

Kann aber auch am Debugger liegen.
Übersetze mal das Programm als Release und probiere das ganze nochmal.
Ich selbst verwende XE2 und hier kommt der Debugger nicht mehr mit Shell-Aufrufen zurecht und bremst diese erheblich aus.
Ich verwende z.B. die JamShell Software und hier wird ein Aufruf im Debugmode mehrere Minuten ausgebremst.

Peter

[Captnemo]

Bei einem sich sehr langsam öffnender Open- oder Save-Dialog kann es auch daran liegen, dass irgendwo noch eine Laufwerksmapping rumschwirrt, dass nicht erreicht werden kann.
Wenn ein gemapptes Laufwerk mangels Ziel nicht zur Verfügung steht, versucht Windows diese mitunter recht lange doch noch zu erreichen, und solange reagiert der Dialog bzw. die Anwendung schlecht bis gar nicht.

Einen ähnlichen Effekt habe ich auch schon mit defekten CD's oder CD-Laufwerken beobachtet.

Allerdings sollte das sowohl zur in der IDE und auch beim direkten Starten gleichermaßen auftreten, ist aber sicherlich in der IDE noch extremer.

[jbg]

Wenn ein Debugger an einem Programm hängt (egal ob es mit oder ohne Debugsymbole kompiliert), dann schaltet der Heap-Allocator (HeapAlloc/HeapFree) in den Debugmodus und verlangsamt sämtliche Speicher Allozierungen und Freigaben von allen Programm/DLLs mit Speichermanagern, die nicht wie FastMM auf VirtualAlloc basieren. Dazu zählt VisualC++'s malloc und natürlich die direkte Verwendug von HeapAlloc.

Dem kann man über die Umgebungsvariable _NO_DEBUG_HEAD=1 entgegenwirken. Aber das alleine hilft nicht. Der weit größere Zeitverbrauch kommt durch das Starten von Threads durch all die ShellExtensions. Dabei bremst der Debugger sehr stark aus. Vor allem der Debugger von Delphi/C++Builder, da er eine "WaitForDebugEvent => PostMessage an DebugWindow-Thread => WaitForSingleObject" Architektur hat, die zusätzlich Zeit verbraucht.

[Der schöne Günther]

Danke, das erklärt einiges. Die ganzen Threads die bei so einem Dialog auf- und zugingen sind mir auch schon aufgefallen.