Delphi XE4 FAQ

[sh17]

Wie sind auch am überlegen, ob wir es bei XE3 belassen und auf Oxygene umsteigen.

Nur was nimmt man dann? WPF, WinForms, QT,GTK,...? Sind doch auch schon wieder alles Auslaufmodelle. Oder Oxygene für Java bzw Nougat - wäre auch eine Option ;-)

[Bernhard Geyer]

Zitat:

Zitat von sh17 (Beitrag 1212241)

Wie sind auch am überlegen, ob wir es bei XE3 belassen und auf Oxygene umsteigen.

Nur was nimmt man dann? WPF, WinForms, QT,GTK,...? Sind doch auch schon wieder alles Auslaufmodelle. Oder Oxygene für Java bzw Nougat - wäre auch eine Option ;-)

Die Frage ist welche Plattform die Anwendung haben soll? Windows (Dann kann man es bei VCL lassen)? MacOS? iOS? Android? Webbasiert?

[hanspeter]

So richtig ist im Moment noch nicht zu erkennen, auf welche Technologie man bei längerfristigen Projekten setzen soll.
Delphi hat ja zum Programmieren per Click und Paste verleitet, so sehen dann auch alte Programme aus.
Mehrschichtsysteme kamen erst später und benötigten in Delphi einige Klimmzüge.
Ich meine das man, gerade bei alten über Jahre gepflegten Projekten die Technologie überdenken sollte.
Vorallen müsste eine schrittweise Umstellung/Modernisierung möglich sein.
Da stehen bei Firemonkey wohl Kompatibilitätsprobleme mit der VCL an.
Eine mögliche Überlegung wäre:
Die GUI relativ schlank auf Web-Basis (HTML). Da ist man mehr oder weniger Plattform - unabhängig.
Die eigentliche Verarbeitung auf dem Server, da ist die Programmiersprache fast egal.

Ich habe z.B. ein relativ großes Programm (ca. 2 Mio Quellzeilen) zu pflegen.
Hier werden an mehreren Arbeitsplätzen Prüfergebnisse eingegeben.
Mit Drücken des Speicherbuttons pflegt das Programm die Daten ein, mit relativ viel SQL-Verkehr in beiden Richtungen.
Das Programm nimmt die gesamte Verarbeitung vor.
Genauso gut könnte man die Eingabe in einen Servercache ablegen.
Die GUI erhält dann irgendwann vom Server die Aufforderung zum Update der Oberfläche.
So ein Construct sollte sich auch einfacher testen lassen. Serverseitig nur ein Eingang (Cache) und ein Ausgang (fertig).
GUI mit Simulationsprogramm bedienbar.

Peter

[Daniel]

Das sind alles legitime Überlegungen - aber nicht in diesem Thread. Schon jetzt ist der Titel "XE4 FAQ" praktisch nicht mehr haltbar.

[Robotiker]

Zitat:

Zitat von Daniel (Beitrag 1212245)

Schon jetzt ist der Titel "XE4 FAQ" praktisch nicht mehr haltbar.

Was die neuen Compiler angeht, sehe ich das eigentlich nicht so. Das sollte schon in einer FAQ stehen.

Mit den Strings und ARC entsteht eine Problematik, die die Kunden schon kennen sollten. Eine homogene Entwicklungsplattform für unterschiedliche Zielsysteme ist das eher nicht, eher eine Brücke für Bestandskunden, um ihre bestehenden Anwendungen auf neue Ziele zu portieren.

Der von mir verlinkte Thread ist ja auch von einem Kunden gestartet worden, der die Beschreibung vom C++ Builder wohl etwas falsch verstanden hat. "Entwicklung in modernem C++ und für Win32, Win64 und Mac", meint eben nicht, dass man das alles gleichzeitig bekommt.

[Insider2004]

Zitat:

Zitat von hanspeter (Beitrag 1212244)

So richtig ist im Moment noch nicht zu erkennen, auf welche Technologie man bei längerfristigen Projekten setzen soll.
Peter

Win32/Win64 VCL ist und bleibt natürlich erst mal die Hauptzielrichtung. In 5 Jahren kann man dann schauen, ob FMX stabil geworden ist. Dann vielleicht ein paar Piloten portieren. Im Moment ist das absolute Spielwiese. Qt hat 20 Jahre gebraucht, um wirklich stabil und anwendbar zu sein. FMX ist erst 2 Jahre alt und das merkt man auch.

[Daniel]

Zitat:

Zitat von Robotiker (Beitrag 1212247)

Zitat:

Zitat von Daniel (Beitrag 1212245)

Schon jetzt ist der Titel "XE4 FAQ" praktisch nicht mehr haltbar.

Was die neuen Compiler angeht, sehe ich das eigentlich nicht so. Das sollte schon in einer FAQ stehen.

Dem stimme ich zu. Nur wie viele von den jetzt 77 Beiträgen werden dem Charakter einer FAQ (inkl. den dazu passenden Antworten) gerecht? Ein Bruchteil. Das war es, worauf ich hinaus wollte.

[Bernhard Geyer]

Zitat:

Zitat von Robotiker (Beitrag 1212247)

Mit den Strings und ARC entsteht eine Problematik, die die Kunden schon kennen sollten. Eine homogene Entwicklungsplattform für unterschiedliche Zielsysteme ist das eher nicht, eher eine Brücke für Bestandskunden, um ihre bestehenden Anwendungen auf neue Ziele zu portieren.

Hier wären Beispiel nötig wie man sowas praktisch angehen sollte damit es möglich bei allen Komponentenherstellern gleich gehandhabt wird.
Soll man alle Stringoperation in Hilfsfunktionen packen und mit $IFDEF ZEROBASEDSTRINGS ... arbeiten.
Oder den Quellcode mit ifdef's durchsieben.
Es ist zwar schön das man hier auf den Standard geht (.NET/Java haben ja auch 0-Basierte Strings), ist aber viel Aufand den Code plattformunabhängig zu gestalten.

[EDIT]
Ich denke mit Abschnitt http://docwiki.embarcadero.com/RADSt...S_from_Desktop wird einiges klar.
Man nähert sich mit der Umstellung der Implementierung die man unter .NET/Java eh machen würde an.

[jensw_2000]

http://docwiki.embarcadero.com/RADSt...S_from_Desktop

Was heißt das denn jetzt im Klartext für mich als VCL Entwickler?

Kommt durch diese String Umstellung in der RTL wieder ein gigantisch zeitraubender Umbau meiner Projekte auf mich zu, mit tausenden von IFDEFS, damit sich die Projekte auch noch mit D2010...XE3 kompilieren lassen? Dann würde ich trotz Wartunsgvertrag dankend auf das Update verzichten.

Oder betrifft mich das ausschließlich, wenn ich meine Projekte doch mal Firemonkey umstellen möchte, um sie dann für iOS bzw. OSX zu kompilieren?
Das wird nur passieren, wenn ich mit Nougat nicht zurecht komme. Cross Platform via Firemonkey bekommt bei mir keinen Vertrauensvorschuss mehr. Das habe ich mit XE2 gekauft, war unbrauchbar, mit XE3 war es weg und in der XE4 "What's new List" steht es als brandneues Top-Feature wieder drin.

[Insider2004]

XE4 enthält die alten Win32/64 compiler. Da hat sich nix geändert. Der neue Mobile Compiler für ios hat die neuen Strings. Es gibt sogar einen Schalter zum Abschalten nur wird in der Doku abgeraten, den für den gesamten Code zu aktivieren. Keine Ahnung, was da dahinter steckt. Wenn Du nur VCL machst, dann überspringe XE4, wenn du Mobile machen willst, dann heisst es Umstellen in XE4. Aber das kommt früher oder später für alle Compiler. Ausserdem ist das with-Statement auch nicht mehr gerne gesehen.

Zitat:

Zitat von jensw_2000 (Beitrag 1212274)

http://docwiki.embarcadero.com/RADSt...S_from_Desktop

Was heißt das denn jetzt im Klartext für mich als VCL Entwickler?

Kommt durch diese String Umstellung in der RTL wieder ein gigantisch zeitraubender Umbau meiner Projekte auf mich zu, mit tausenden von IFDEFS, damit sich die Projekte auch noch mit D2010...XE3 kompilieren lassen? Dann würde ich trotz Wartunsgvertrag dankend auf das Update verzichten.

Oder betrifft mich das ausschließlich, wenn ich meine Projekte doch mal Firemonkey umstellen möchte, um sie dann für iOS bzw. OSX zu kompilieren?
Das wird nur passieren, wenn ich mit Nougat nicht zurecht komme. Cross Platform via Firemonkey bekommt bei mir keinen Vertrauensvorschuss mehr. Das habe ich mit XE2 gekauft, war unbrauchbar, mit XE3 war es weg und in der XE4 "What's new List" steht es als brandneues Top-Feature wieder drin.