Open und Savedialoge zu langsam

[Metschu]

Hallo,

ich habe ein Problem, das die Open- und Savedialoge aus der IDE bis zu 30 sec dauert, bis der Dialog soweit aufgebaut ist, das man damit arbeiten kann.
Weitere 5 sec nach dem klicken auf OK. Dann läuft alles wieder Flüssig.

Sowohl mit dem Open, als auch mit dem Save Dialog.
Die Pfadvorgabe ist die Lokale Festplatte, kein Netzwerk.

In der Fertigen .exe läuft alles super flüssig.

Die geschieht sowohl im Debug Modus, als auch im Release Modus.

Hat jemand eine Idee?
Nervt ein wenig

Danke!

Gruß

Torsten

[Bernhard Geyer]

Liegt ne Zip-Datei im zu öffnenten Verzeichns?
Ansonsten gibt es viele schlecht Programmierte Shell-Extensions

[Der schöne Günther]

Also 30 Sekunden sicherlich nicht, aber dass das bei laufendem Debugger DEUTLICH länger braucht ist mir auch schon aufgefallen.

[Popov]

Hast du 1 oder 2 externe Festplatten? Die schalten sich gerne nach einer Minute ab und müssen erst wieder gestartet werden.

Hast du ein CD/DVD Laufwert und das ist eine CD drin?

[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.

[Perlsau]

Wie bereits richtig erkannt, hängt die Trägheit der Open- und Save-Dialoge beim Start in der IDE mit dem Debug-Modus zusammen. Damit muß man dann irgendwie leben. Kann man auch: Als Quasi-Notlösung habe ich mir angewöhnt, dort, wo ich beim Testen regelmäßig Open- und/oder Save-Dialoge benötige, für die Zeit des Testens und Entwickelns den Aufruf des Dialogs vorübergehend auszukommentieren und durch einen "fest verdrahteten" Dateinamen zu ersetzen.

Delphi-Quellcode:

Funktion DateiEinlesen : String;
begin
//  If OpDlg.Execute
//  Then
//    Result := OpDlg.FileName
//  Else
//    Result := '';
  Result := 'C:\Temp\MeinText.txt';
end;

Zitat von jbg:

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.

Das ist heftig, da kann man sich einen Wolf warten, soviel Kaffee kann man gar nicht schlucken, wie man da jeden Tag kochen könnte.

Was ich jetzt nicht auf Anhieb verstehe: Was meinst du mit ShellExtensions? Sind das die Erweiterungen, die im Objektmenü des Explorers auftauchen? Wenn ja, würde es was bringen, diese beim Entwickeln vorübergehend abzuschalten?

[Uwe Raabe]

Zitat von Perlsau:

Was ich jetzt nicht auf Anhieb verstehe: Was meinst du mit ShellExtensions? Sind das die Erweiterungen, die im Objektmenü des Explorers auftauchen? Wenn ja, würde es was bringen, diese beim Entwickeln vorübergehend abzuschalten?

Probiers doch einfach aus.