Delphi 10.4.1 verfügbar

[Uwe Raabe]

Zitat:

Zitat von Frickler (Beitrag 1473118)

Dazu hat mich extrem genervt, dass der Umschalter zwischen Code/Design/Historie nicht unten links, sondern unten rechts ist. Für jemanden, der von links nach rechts schreibt, ist das ein ziemlich langer Mausweg, wie ich finde. Und ich hab nirgendwo gefunden, wie man das umstellen könnte.

Ich muss zugeben, das hat mich anfangs auch ziemlich gestört. Nach ein paar Tagen mit 10.3 war das allerdings schon in Fleisch und Blut übergegangen und jetzt stört mich eher das alte Layout.

[OlliWW]

Zitat:

Zitat von Kostas (Beitrag 1473068)

Wird eigentlich das IDEFixPack noch benötigt?

Oh ja.

Ich arbeite nun seit einigen Wochen mit 10.4. testweise. Nutze nun auch schon 10.4.1.

Für große Projekte ist es wie immer alles viel zu träge und buggy. Deshalb sitzt der Rest unserer Entwicklungsabteilung weiterhin auf 10.3. bis es hoffentlich ein IDE Fixpack gibt.

In einem kleinen losgelösten Projekt habe ich 10.4.1. auch ausprobiert, dort kann man normal arbeiten, wobei ich in einem Projekt mit 4 Units eine Wartezeit von 3 Sekunden bei "STRG + Mausklick" auf einen Typen, doch recht lange finde.

Ich weiß gar nicht ob Embarcadero sich dessen bewusst ist: Gibt es eines Tages kein IDE Fix Pack mehr, ist die IDE z.B. für unsere Firma nicht mehr zu gebrauchen und wir werden uns dann leider anderen IDEs und damit Sprachen zuwenden müssen, da es effizientes Arbeiten dann nicht mehr möglich ist. Da helfen dann auch keine Bluetooth Beacons und Dark Theme

[himitsu]

Zitat:

Zitat von Frickler (Beitrag 1473118)

Wir sind auch noch bei XE6. Verglichen damit waren sämtliche 10.x Versionen, die ich angetestet habe, instabil und lahm.
Ist das bei 10.4.1 anders? Wie ist der Unterschied zu XE.

Selbst wenn es von den bugs her bissl mehr hat, als XE(1), kann es nur besser werden.
* AutoSave der Units, wenn die IDE mal wieder verreckt (was oft genug passiert, auch durch eigenen DesignCode)
* viele andere Bugs sind behoben (also ist genug Platz für Neue)
* neuere wesentlich praktischere Features in der Sprache

Ich bin bald/demächts/... dabei von XE auf 10.4 umzurüsten, also abschließend Genaues kann ich noch nicht sagen.
Aber so oder so, umgstellt wird ganz bestimmt ... selbst wenn es schlussendlich nicht auf 10.4 sein sollte, dann würde es mindestens 10.3.
Muß nur noch den letzten DevExpress-CodeUmstellungs-Bug beheben, dann ist "vermutlich" alles bereit.

Erste Teiltests noch mit 10.1/.2 verliefen nahezu problemlos.


Und ja, das IDE Fix Pack haben/hatten wir bis jetzt auch drin.
Wobei die größte Compilierarbeit multithreated im FinalBuilder abläuft ... da kommt die IDE eh nicht ran.
(Problem ist aktuell noch Eurekalog, was beim Multithread bissl zickt, weil ich dessen DCUs noch nicht vorkompiliere und der daher das für jede EXE/DLL, wegen dem "Build" statt "Compile", neu kompiliert und sich ab und an überschneidet)



Andere "bessere" IDE/Sprache?
Sowas gibt es nicht :zwinker:, jedenfalls nicht mehr, wenn er in diesem Millenium zurück kommt.
https://edn.embarcadero.com/print/20297

Leider kommt er, laut Einstein, frühestens in 5 Millionen Jahren zurück, da die nächste Galaxie 2,5 Mio Lichjahre entfernt ist. :cry:

[jaenicke]

Zitat:

Zitat von Frickler (Beitrag 1473118)

Wir sind auch noch bei XE6. Verglichen damit waren sämtliche 10.x Versionen, die ich angetestet habe, instabil und lahm.
Ist das bei 10.4.1 anders? Wie ist der Unterschied zu XE?

Ich ärgere mich jedes Mal, wenn ich mal mit XE6 arbeiten muss, weil das ständig hängt und beim Debuggen abstürzt (spätestens in einer Projektgruppe). Dagegen laufen 10.2 und 10.3 sehr gut. Und 10.4.1 ist noch einmal spürbar schneller als 10.4 oder davor.

Delphi XE hatte bei Generics immer wieder mal interne Fehler, die ein Neuerzeugen notwendig machten, war ansonsten etwas stabiler als XE6, aber auch langsamer und instabiler als 10.x.

[t2000]

OT:
Mich wundert es doch immer wieder, wie viele hier noch an alten Mamunt Monolth Projekten arbeiten.
Wir haben 2016 das letzte > 1 Millionen Zeilen Projekt eingestellt, bzw. supporten nur noch schlimme Bugs.
Unsere neuen Projekte sind alle sehr viel kompakter.

[dummzeuch]

Zitat:

Zitat von Frickler (Beitrag 1473118)

Dazu hat mich extrem genervt, dass der Umschalter zwischen Code/Design/Historie nicht unten links, sondern unten rechts ist. Für jemanden, der von links nach rechts schreibt, ist das ein ziemlich langer Mausweg, wie ich finde. Und ich hab nirgendwo gefunden, wie man das umstellen könnte.

Da gibt es Umschalter für? ;-)

Ich schalte immer mit F12 zwischen Code und Designer um. Die Historie habe ich noch nie benötigt.

[Frickler]

Zitat:

Zitat von dummzeuch (Beitrag 1473156)

Ich schalte immer mit F12 zwischen Code und Designer um. Die Historie habe ich noch nie benötigt.

Die Historie ist super praktisch falls man mal unterbrochen wird - wo war ich, was passierte davor? Zudem zeigt sie nicht bloß, was Delphi selbst gespeichert hat, sondern greift auch auf die Versionsverwaltung (bei mir Subversion) zu. Kann ich natüüüürlich auch mit Tortoise nachsehen, aber so gehts schneller.

[Kostas]

Ich habe heute D10.4.1 innerhalb einer VM Ware Workstation 15.5.6 mit allen Fremdkompositionen die wir so benötigen zum Laufen gebracht.
Wir haben ein Projekt mit dem DataSnapServer. Die gute Nachricht, Client kompiliert mit D10.3.2 kann mit dem DataSnapServer kompiliert mit D10.4.1.
Dann habe ich das Projekt geöffnet un es fällt auf, die IDE benötigt deutlich länger um Forms zu öffnen. Dann habe ich mal 187 Form zu öffnen ausgewählt. Der Proz ging auf 50% und die anderen 50% hat sich der LSP Server gepackt. Nach ca. 5 Min. war Schluss mit Lustig und die IDE ist abgeraucht. Naja, ist nicht so schlimm. So viele Forms öffnet man ja normal nicht. Der Hintergrund war, wenn man mit Alt+P+K kompiliert werden nicht immer alle fehlende Controls erkannt. Erst wenn man versucht die Form zu öffnen, dann knallts. Ich muss also jede Form mindestens einmal öffnen.

[himitsu]

Ja, wenn die Unit nicht geöffnet wird, dann wird die DFM-Ressource ungeprüft eingebunden (gelinkt).
Erst zur Laufzeit oder im FormDesigner wird die DFM auch geladen (die Objekte erstellt).

Wir haben im Programm daher auch nochmal einen TestModus, der alle Forms öffnet,
vor allem auch die dynamischen Forms, welche mit Infos aus der DB generiert werden. (dynamische Grids, Edits und Dergleichen)



Man könnte über die OpenToolsApi oder (bedingt) das PreCompile-Script eine Prüfung seiner DFMs/Resourcen einbinden.
Oder zur Laufzeit z.B. via RTTI alle seine Forms suchen und laden.

[Der schöne Günther]

Ich erinnere mich auch dunkel an irgendein Plug-In das mal alle DFM-Dateien öffnete und versuchte darzustellen. Daran konnte man erkennen ob die DFM-Dateien (mal wieder) korrupt waren. Erinnert sich noch jemand wie das geheißen haben könnte?