IDE bleibt hängen

[Nersgatt]

Moin,

Wenn ich mein Projekt öffne, dann wird bei mir das Hauptformular direkt geöffnet. Das passiert auch in einer akzeptablen Zeit.
Wenn ich dann allerdings das Hauptformular in der IDE schließe, friert die IDE für >5 Minuten komplett ein. Danach reagiert sie wieder und ich kann ganz normal an meinem Projekt arbeiten. Dateien öffnen, schließen, speichern, etc., alles normal. Nur das erste Schließen des Hauptformular in der IDE dauert ewig.

Ich hab keine Idee, woran das liegen könnte.
Ich hab schon probiert, den bds.exe-Prozess als Ausnahme im Defender einzutragen. Hat nichts gebracht. Ich hab auch *.pas und *.dfm als Ausnahme eingetragen. Hat auch nichts gebracht.
Das Verhalten habe ich schon länger (mehrere Monate), hatte aber bisher nicht die Muße, mich damit zu befassen. Da es ja nur 1-2 am Tag nervt, wenn man das Projekt öffnet. Daher kann ich auch nicht mehr nachvollziehen, ob es dafür einen bestimmten Auslöser gab.

Ich arbeite mit

• Berlin 10.1 Update 2
• Windows 8 (Version 6.3, Build 9600)
• Komponenten: DevExpress, UniDAC, TMS

Jemand eine Idee?

[jaenicke]

Was sagt denn in der Zeit der Stacktrace? Wirft die IDE irgendwelche Exceptions im Hintergrund? Passiert in der Zeit etwas im Process Monitor?

[Uwe Raabe]

Falls noch nicht geschehen, kannst du mal versuchen die TrackingSystem<nnn>.bpl aus den Known IDE Packages zu entfernen - sowohl unter HKCU als auch unter HKLM. Ein weiterer Kandidat dafür ist die CommunityToolbar<nnn>.bpl.

[Nersgatt]

Das Entfernen der Packages hat leider nichts gebracht.

Ich hab das dann mal mit dem ProcessMonitor untersucht. Es liegt daran, dass er sich an den DCUs kaputt sucht.
Da kommen wohl mehrere Faktoren zusammen:

• zu einem haben wir unseren Code vor einiger Zeit in Unterordner aufgeteilt, um etwas mehr Struktur rein zu bekommen. Das Projekt ist ziemlich groß, lässt sich aber sehr schön in Themenbereiche abgrenzen. Daher schien die Aufteilung in Unterordner sinnvoll. Die IDE sucht nun alle DCUs erst mal in den Projektordnern.
• Die IDE probiert die Unit-Gültigkeitsbereichsnamen (Projektoptionen) durch. Und das wieder in allen Unterordnern mit allen Units
• In den Projektoptionen habe ich ein "Ausgabeverzeichnis für Units gesetzt", da ich die ganzen DCUs nicht im selben Ordner wie die Quellcodedateien haben möchte. Einfach für die Übersichtlichkeit. Und grade in diesem Ordner (wo die IDE die meisten DCUs sofort finden würde) sucht die IDE scheinbar zuletzt.

Diese Faktoren potenzieren sich natürlich.
Ich werde jetzt erst mal versuchen, ob ich auf die Unit-Gültigkeitsbereichsnamen verzichten kann. Das sollte schon Besserung bringen.

Hat jemand ein Tipp zu dem Ausgabeverzeichnis für die Units? Kann man die Suchreihenfolge irgendwie beeinflussen?

[Uwe Raabe]

Wie sieht denn der Suchpfad des Projekts des aus?

[Nersgatt]

Der Suchpfad des Projekts ist leer. Sollte ich da den Ausgabepfad für die DCUs eintragen? Ich dachte, in den Suchpfad gehört nur der Pfad zu den Quelltexten.

[Uwe Raabe]

Zitat von Nersgatt:

Ich dachte, in den Suchpfad gehört nur der Pfad zu den Quelltexten.

Das ist auch korrekt so.

Wenn der Suchpfad leer ist, kommt lediglich noch der Bibliothekspfad aus den IDE-Optionen zum Tragen. Allerdings sollte der DCU-Ausgabepfad eigentlich Vorrang haben.

[Nersgatt]

Interessant ist, dass er immer erst die Unit-Gültigkeitsbereichsnamen durchprobiert.

Mal ein Beispiel, wie ich es im ProcessMonitor nachvollziehen kann. Die IDE sucht die Datei "MyServicesUni.dcu" (eine Datei, die zu UniDAC gehört).
Die IDE sucht nun zuerst nach der Datei "WinApi.MyServicesUni.dcu" in folgender Reihenfolge:

1. Projektordner, in der die DPR liegt
2. Debug-DCU-Pfad
3. Bibliothekspfad
4. Unterordner des Projektes

Dies wiederholt die IDE nun für "System.MyServicesUni.dcu", dann für "Data.Win.MyServicesUni.dcu", usw.
Nach 2714 fehlerhaften Suchen nach der Datei, kommt die IDE endlich mal auf die Idee, nach "MyServicesUni.dcu" zu suchen, welche sie dann im Bibliothekspfad findet.
Würde die IDE nicht erst alle Unit-Gültigkeitsbereichsnamen durchprobieren, hätte sie die Datei schon nach 19 Schritten gefunden, nicht erst nach über 2000.

[Uwe Raabe]

Das sind doch eigentlich Dinge, die erst beim Compilieren auftauchen sollten, oder? Könnte es sein, daß hier Code Insight oder irgendein anderes Tool seine Finger im Spiel hat?

[himitsu]

Zitat von Nersgatt:

Nach 2714 fehlerhaften Suchen nach der Datei, kommt die IDE endlich mal auf die Idee, nach "MyServicesUni.dcu" zu suchen, welche sie dann im Bibliothekspfad findet.

Mal den Andreas fragen, ob er Lust hat dort auch noch einen Cache für die Dateisuche reinzuhacken, damit das Suchen schneller geht.