Delphi 11 IDE friert ein

[Carsten Hölscher]

Ich hatte es jetzt wiederholt, dass mir die gesamte Delphi 11-IDE einfriert. Das Fenster läßt sich noch in der Größe ändern, der Inhalt wird aber nicht mehr aktualisiert. Auch längeres Warten hilft nicht, es bleibt nur der Taskmanager.
Ich bin nicht ganz sicher, aber ich meine es kam immer beim Umschalten von 32 auf 64 bit und anschließendem Erzeugen des Projekts.
Ist immer etwas ärgerlich wenn man den letzten Stand nicht gespeichert hatte.
Hat jemand nen Tipp dazu?

Carsten

[stahli]

Eine interessante Frage ist sicherlich, ob Du irgendwelche Packages installiert hast oder daran arbeitest.

[Carsten Hölscher]

Es ist ein großes Projekt (hab's eben im Projekte-Forum kurz umrissen) und es sind neben dem Standardumfang ein paar Komponenten im Einsatz. Ein paar eigene, meist etwas erweiterte Standardkomponenten. Das einzige größere ist das Menüsystem SpTBX.
Wenn die IDE nicht gerade abstürzt, läuft aber alles rund und die exe wird korrekt erzeugt.

Carsten

[Carsten Hölscher]

Nachtrag: GeExperts hab ich noch installiert und eben festgestellt: Wenn ich auf das X im Fenster klicke, kommt sogar eine Abfrage ob ich vor dem Schließen speichern möchte. Das bekommt die IDE dann auch trotz ihres komatösen Zustands hin. Damit ist das Ganze dann doch ganz gut handlebar.

Carsten

[himitsu]

Zitat:

Ist immer etwas ärgerlich wenn man den letzten Stand nicht gespeichert hatte.

Es wird doch inzwischen automatisch gespeichert? (siehe _recovery-Verzeichnis)

Allerdings hab ich bei mir diese Zeit etwas runtergeschraubt. Minütlich beruhigt da ungemein.

Beim nächten Öffnen des Projktes / der Datei wird wird dann gefragt "hab 'Ungespeichertes' gefunden, soll das geladen werden?".



Es gab/gibt auch immernoch die Option, wo "beim Kompilieren" gespeichert wird,
aber diese Option war für uns eh total unnütz, da sie nicht "beim", sondern "nach" dem Kompilieren speichert und bei uns meißtens die IDE mitten im Kompilieren abkratz, also bevor gespeichert würde.





Wie oft passiert das denn?
Man könnte sich zwar auch nach dem Hängenbleiben mit einer weiteren IDE/Debugger dranhängen, aber besser lief es immer, wenn der Debugger schon vor dem Hängen mitlief.
> eine IDE starten und da im Debugger die eigentliche Arbeits-IDE starten
Und dann auf eine Exception in der IDE warten, oder beim Hängen auf ⏸ klicken und schauen, ob man sieht, wo der Hauptthread grade hängt.

[zeras]

Gab es nicht auch mal Probleme mit Antivirenscannern?

[himitsu]

Die gibt es doch immer.

[Carsten Hölscher]

Das Autospeichern will ich auch nicht immer haben. Manchmal teste ich nur was und verwerfe dann einfach die Änderung ungespeichert.
Klar kann man alles anders machen aber seit ich gemerkt hab, dass die Speicherabfrage noch kommt, ist es ok für mich.
Gestern hatte ich das so ca. 5 mal.

Carsten

[himitsu]

Jupp, daher hab ich das "alte" AutoSpeichern bei mir immer aus.

Aber das betrifft nur das "direkte" Speichern der PAS/DPR/DFM/...
Dank Versionierung (SVN/GIT/HG) wäre es zwar fast egal, wenn dabei die Dateien geändert werden.
Oder wenn ohne Versionierung, dann über die _history.
Und dann gibt es noch "Rückgängig nach Speichern".
So kommt man ja immer an alte Stände ran, auch wenn ich es schon bissl nervig finde, da ich auch gern mal kurz war probiere/teste/bastle, was nie gepsiechert werden soll.

Seit Kurzem gibt es nun auch die "Sicherung" im _recovery, was nicht direkt die Datei speichert/ändert, sondern daneben,
womit dann auch sowas wie basteln>kompilieren>ausführen>wegwerfen problemlos geht.

Nachteile, die Emba noch reparieren muß:

• bei ungespeicherten Dateien/Projekten wird _recovery zwar gespeichert, aber nicht automatisch geladen und bei einem nochmal "Neuen Projekt" auch überschrieben und man muß selber vorher die Sicherung öffnen
• bei "Schreibgeschützten Dateien", da gehen ständig Fehlermeldungen auf, weil "_recovery" z.B. bei DelphiDateien ala Winapi.Windows.pas nicht gespeichert werden kann ... das braucht es auch nicht, selbst wenn ich in solchen Dateien gern mal bei der Suche was ausschneide/verschiebe/ändere, aber eh nicht vor habe es jemals "dort" zu speichern

Bei uns raucht Delphi oftmals ab, durch "eigene" Fehler in DesignTimePackages, wenn man Diese kompiliert.
Im neuen Delphi (aktuell wird immernoch hauptsächlich in XE gearbeitet, aber 10.4/11 ist nun endlich nahezu fertig und zumindestens ich hab damit schon mehrmals etwas gearbeitet gespielt.
Bissl nervg empfinde ich immernoch das IDEInsight, aber zum Glück ist es im 11 nun nicht mehr ganz so pervers transparent.
Pervers nervig ist noch das LSP, was bei Autovervolständigung IMMER hängt oder ewig braucht und man NIE erkennt, ob es nun nur hängt und doch noch kommt oder ob es schon abgekratzt ist und nie aufpoppt. Manchmal geht es auch später doch plötzlich auf und überschreibt was, weil ich schon am Weitermachen war.
.....

[jaenicke]

Zitat von himitsu:

Es gab/gibt auch immernoch die Option, wo "beim Kompilieren" gespeichert wird,
aber diese Option war für uns eh total unnütz, da sie nicht "beim", sondern "nach" dem Kompilieren speichert und bei uns meißtens die IDE mitten im Kompilieren abkratz, also bevor gespeichert würde.

Dann geht da etwas anderes schief. Wenn der Kompiliervorgang anfängt, ist der Speichervorgang definitiv angeschlossen. Ich habe es eben auch noch einmal mit einem Abschießen der IDE per Taskmanager ausprobiert. Es war alles gespeichert, was ich direkt vorher geändert hatte, obwohl ich noch im Prebuild Ereignis war (ich hatte in der Batchdatei ein 5s Warten eingebaut).