dort wird der Code mit Visual Studio Code geschrieben (und diversen Plugins), und seitdem bin ich jedes mal erstaunt, wie langsam und träge Delphi dagegen wirkt.
Mit Visual Studio Code kann man übrigens auch Delphi-Code schreiben:
https://marketplace.visualstudio.com...gies.delphilsp
Würde Embarcadero eine schnelle, moderne
IDE auf den Markt bringen, die die bereits mehrfach angesprochene Plattformunabhängigkeit mitbringt, könnte es möglicherweise die jüngeren Kollegen dazu bringen, sich Delphi anzuschauen. Ich denke, die Sprache an sich ist nicht das Problem, sondern eher das Werkzeug.
Ja, leider ist die
IDE immer noch nicht gut, so sehr bei diversen Releases betont wurde, dass man sich dort auf Fehlerbehebung konzentriert. Die Probleme mit Code Insight / LSP sind nur die offensichtlichsten, aber es gibt ja noch einige andere (Refactoring, ...).
Das in Kombination mit diversen konstruktions- und qualitätsbedingten Problemen in neueren
VCL- und
RTL-Quelltexten (nicht oder schlecht nutzbare Funktionalität, fehlende Kapselung, fast schon Spaghetticode teilweise, ...) macht leider keinen guten Eindruck. Leider hat man an manchen Stellen keine Wahl als die komplette Klasse oder
Unit zu kopieren und zu korrigieren oder mit Hooks und anderen Tricks zu arbeiten, nur damit die vorgesehene Funktionalität möglich ist. Und man sitzt dann davor und denkt nur noch: "Wie um alles in der Welt kann man auch nur auf die Idee kommen das so umzusetzen?"
Ein Beispiel:
Die CustomTitleBar. Da kann man eigene Buttons definieren, bekommt aber keinen Zugriff auf die Positionen der Buttons. Man kann also andere Controls nicht ohne Tricks daneben platzieren. Denn man bekommt nur ein paar wenige Informationen, der Rest ist nur in dem Buttonobjekt selbst drin und das steht unter protected. Das Buttonobjekt bekommt man im OnPaint als Sender übergeben. Die Ermittlung der Darstellungsinformationen wie die Farben ist aber nicht gekapselt, sondern stattdessen sind die Zeichenroutinen in überlangen unstrukturierten Methoden untergebracht. Ich sage nur "separation of concern", "clean code" Prinzipien, was früher auch mal in den
RTL- und
VCL-Quellcodes beachtet wurde. Jedenfalls kommt man an diese ermittelten Farben nicht ohne Tricks heran, so dass man den Code im Grunde kopieren muss, damit die Buttons genauso aussehen. Ach ja, die Custom Buttons sind übrigens einen Pixel höher als die anderen Buttons.
Dazu kommt, dass die Standard-Buttons sich nur deshalb korrekt verhalten, weil diese das Fenster manipulieren. Wenn man aber etwas anderes auslöst, klappt schon der Hovereffekt usw. nicht mehr korrekt.
Ach ja, und die Colormap vergisst manchmal plötzlich alle Farben, so dass ich diese im Quelltext setzen muss.
Wie habe ich es korrigiert? Ich habe die Instanz der CustomTitleBar über den Schreibtrick auf Properties ohne Getter ausgetauscht und bekomme so z.B. das Rechteck, in dem sich die Buttons befinden. Und ich greife über den üblichen Trick auf die Protected-Elemente zu. Und noch ein paar andere Sachen...
Wenn das nun alles funktioniert, kann ich mal schauen, wofür es schon Quality-Einträge gibt.
Die Titelleiste der Delphi-
IDE hat diese Probleme alle nicht, aber offensichtlich wurde nicht die gleiche Komponente auch veröffentlicht. So funktioniert dann auch "eat your own dog food" nicht.
Ich mag Delphi, aber wenn ich andere Sprachen nutze, mögen zwar manche IDEs weniger Features haben, aber sie laufen sehr viel stabiler und schneller. Leider.