Nach all den Jahren hat man sich an Strg+Shift+S gewöhnt.

Und das Autospeichern hat ein klitzekleines Problemchen.
Es speichern nur erst nach dem erfolgreichen Kompilieren, aber zu 80% raucht die IDE bereits schon beim Kompilieren ab.


Also ich überseh das nicht,
Bei Einzeilern mach ich eigentlich kein BEGIN ... war nur für die Demo
und ansonsten zeigt eine "ordentliche" Codeeinrückung ganz deutlich, daß es da ein BEGIN geben muß.

Zitat von himitsu:

Und das Autospeichern hat ein klitzekleines Problemchen.
Es speichern nur erst nach dem erfolgreichen Kompilieren, aber zu 80% raucht die IDE bereits schon beim Kompilieren ab.

Das ist falsch, das habe ich eben noch einmal extra getestet. Kleine Änderung, kompilieren gedrückt und direkt den Prozess abgeschossen, die Änderung war gespeichert, obwohl der Compiler noch nicht einmal bei der ersten Quelltextdatei angekommen war (der Anzeige nach).
Da bei mir bisher bei Abstürzen immer die letzten Änderungen schon gespeichert waren, auch wenn die IDE beim Kompilieren abgestürzt ist, konnte das aber auch nicht so sein.

Zitat von himitsu:

und ansonsten zeigt eine "ordentliche" Codeeinrückung ganz deutlich, daß es da ein BEGIN geben muß.

Schönreden kann man eh alles.
Ich mache bei fremdem Code ohnehin zuallererst ein Strg + D, insofern stört mich das eh nicht wie der Code vorher aussah.

Ich finde es aber eben auch nicht schlimm, wenn Features wie das genannte eben nur bei standardkonformem Highlighting auch korrekt aussehen. Dafür gibt es nun einmal Standards. Es macht ja auch niemand ein DIN A4 Blatt mal eben 5 Zentimeter größer und beschwert sich dann, dass es nicht in einen A4 Hefter passt und dieser also kaputt ist.

Das war das AutoSave von den DDevExtensions, aber ich kram jetzt nochmal die alte D7 und XE VM raus und probier es ohne alles.

Wenn du das cnPack installiert hast, dann macht Strg+D aber nicht das, was du willst,
wobei Strg+Shift+F auch nicht das macht, was ich will.


Was aber nie beim Compilieren gespeichert wird, istdie Desktopdatei.
Die wird auch nie gespeichert, wenn man "Alles speichern" ausführt,
sondern blöder Weise nur beim beenden der IDE, bzw. beim Schließen des Projekts/Projektgruppe.

Zitat von himitsu:

Wenn du das cnPack installiert hast, dann macht Strg+D aber nicht das, was du willst,

Doch, weil unserer in der Installationsprozedur drin steht, wie man den Shortcut im CnPack korrigiert.

Ich finde es allerdings sehr schade, dass Delphi die Shortcuts einfach so umbiegen lässt ohne dass man das verhindern kann.
In einem meiner Programme kann man die Shortcuts auch aus Add-Ons heraus ändern, nur werden die dann in den Einstellungen in einer Liste aufgeführt, in der man die Shortcuts sieht inkl. Warnzeichen, wenn dadurch ein anderer Shortcut überschrieben wurde. Dort kann man den ursprünglichen Shortcut auch fixieren, so dass er nicht mehr umgebogen werden kann.

Das ist allerdings kein Fehler, nur ärgerlich, gehört daher auch nicht in diesen Thread.

In dem Fall ist auch auch nicht ein "Bug" im Delphi, sondern bei den Chinesen, welche nicht nachgeschaut haben, ob sich hinter dem Shortcut seit Jahren nicht vielleicht schon etwas befindet.

Aber ich kann mich jetzt auch nicht erinnern, daß sich in der OTA eine Funktion befindet, mit der man einen ShortCut auf Belegung prüfen könnte. (das wäre dann ein Fehler Fehlender)

Zum Glück muß ich mit XE8 nicht produktiv arbeiten, sonst würde es mich nerven, wenn der Codeeditor ab und an einfach abschaltet und keine Lust mehr hat die Anzeige zu malen.
Ein Neustart behebt es allerdings.

An vollem RAM liegt es scheinbar mal nicht, also vermutlich ein weiterer Castalia-Bug.

Da das bei mir nicht passiert und ich Castalia deaktiviert habe, liegt die Vermutung nahe...

Mehrfach Exceptions in Castaliakeyboard.TCastaliaKeyboardManager.FindShortcut , beim Einfachen drücken eines Buchstabens (Schreiben von Code)
Deinstallieren ist wohl wirklich die einzige Lösung. (ich hoffe es dauern nicht genauso lange, wie beim AQTime, bis die IDE nicht meht so oft abtürzt)

Blöd nur, jetzt fällt ein das größte Verkaufsargument für XE8 weg)
http://www.delphipraxis.net/185023-1...ilder-xe8.html
Jetzt sind es nur noch 13 und das ist doch angeblich eine Unglückszahl.



Und das im GetIt Vieles doppelt oder dreifach in der Liste steht, ist bestimmt nur ein temporäres Problem?
Nja, zumindestens sieht es so voller aus.

[edit] Ich seh grad, daß es nicht nur bei mir so ist.
http://www.thedelphigeek.com/2015/05...ary-getit.html

Es handelt sich hier eigentlich nicht um mehrfache Einträge, sondern um die verscheidenen Versionen für die verschiedenen Personalities ( Delphi/C++Builder jeweils 32 Bit und 64 Bit).

Daß es nicht das "Selbe" ist, hab ich gemerkt, als ich mal probehalber den VTV installiert hab und danach nicht beide auf "instlaliert" standen.

Aber wäre natürlich praktisch, wenn man auch erkennen würde, was was ist, denn an der Bezeichnung und nichtmal an der Beschreibung kann man keinerlei Unterschied erkennen.
Oder GetIt zeigt einfach das nicht an, was nicht für mich gedacht ist.

Ich wusste nichtmal, daß es den VTV für verschiedene Personality gibt. Ist bei Editionen für kleinere Delphi da dann irgendwas weniger drin?