RAD Studio XE7: Was Entwickler davon halten...

**kuba**

Ich habe hier immer noch zusätzlich eine ältere Delphi Version installiert, für den Fall der Fälle ...

In einigen Tagen vollziehe ich ebenfalls ein Upgrade von XE2 auf XE7. Zuvor hatte ich 2005, 2010 und XE im Einsatz. Bisher gefiel mir XE2 am besten und zwar wg. der Möglichkeit auch 64-Bit Anwendungen zu kompilieren. Der Grund für das Upgrade ist die angeblich letzte Möglichkeit upzugraden. Weiterhin interessiert mich brennend was sich in den letzten Jahren so getan hat, würde auch gern mal ein App in Umlauf bringen. So ein Upgrade ist ja schon recht teuer, da sich in den letzten Jahren vieles verändert hat muss es jetzt mal sein ...

kuba

**jaenicke**

Zitat von himitsu:

Bei mir ist es eher andersrum, nachdem die ersten gebrannten Sicherungskopien nicht mehr lesbar waren, landet das auf 2 ab und an gespiegelten Backupfestplatten.

Das kommt dann aber auch sehr darauf an was man für Rohlinge gekauft hat. Bei mir sind noch die CDs mit meinen ersten Sicherungskopien aus meiner Schulzeit problemlos lesbar, genauso wie später dann die ersten DVDs.
Von anderen Rohlingen, die ich größtenteils von anderen bekommen habe, die diese bei Discountern oder in Schnäppchenaktionen gekauft haben, sind hingegen sehr viel weniger noch lesbar.

Da man Delphi aber ohnehin einfach wieder herunterladen kann, brenne ich die ISOs auch nicht.

**himitsu**

Dank der "Upgrade von jeder Vorgängerversion"-Aktionen ist der Kauf der neusten Version bestimmt günstiger, als der jetzige Kauf einer älteren Vorgänger-Vollversion.
Selbst wenn man also nicht "gleich" die aktuellste Version nutzt (die nächsten 5 Monate sind die Updates/Bugfixe noch kostenlos) ürfte es dennoch güstiger sein, als eine "neuere" alte Vollversion, außer er hat glück und bekommt auf dem Gebrauchtmarkt günstig eine Vollversion, bzw, eine uralte Vollversion inkl. aller aufbauenden Upgrades zu einer "neueren" Version.

Delphi-Preise verfallen irgendwie nicht so wirklich.
Selbt ein gebrauchtes Delphi 2005 Prof kann man für "nur" 800 € bekommen. (teurer, als XE7 und dann nut die alte Version nutzen, wobei man dann immernoch XE7 auch nutzen kann)

**Harry Stahl**

Generell gefällt mir XE7 sehr gut. Der Compiler ist m.E. einer der schnellsten bisher.

Was ich gerade schade finde, sind die immer wieder neuen Bugs von Version zu Version.

Nach stundenlanger Suche habe ich nun herausgefunden, dass jede TDateEdit, welches in einer Windows-FMX-Form liegt, ca. 300 Millisekunden für die Erzeugung braucht.

Bei 4 TDateEdit also ca. 1,2 Sekunden.

Unter XE6 war die Erzeugung nicht messbar.

Böser Bug!!

**Mavarik**

Zitat von RWarnecke:

Aus meiner Sicht, muss man bei solchen Crosscompilern immer Kompromisse eingehen. Ich will die Aussage nicht über einen Kamm scheren, aber mir wird zumindest seitens Emba diese Meinung deutlich vermittelt.

Also der neue Designer aus XE7 ist für mich auch überhaupt nicht zu gebrauchen. Ich habe mir aus Ermangelung eines solchen, unter XE5 schon einen Fenster/Frame Handler geschrieben, der eigentlich genau das macht... Device unabhängig meine Forms darstellen und zwar ohne Kompromisse auf allen Plattformen...

Und nein ich will gar nicht das es so aussieht wie alle Apps je nach Plattform unterschiedlich... Meine App soll wie meine App aussehen und zwar überall gleich... Also Premium-Style verwenden, anpassen und fertig.

Meine App sieht auf iOS, Android, Windows, MacOS immer gleich aus...
Ein Sourcecode!
Nur in meiner eigenen Mobilen-Helper-Unit sind die IFDEF's der Rest ist Plattform unabhängig...

XE6 war hier schon richtig gut. Aber an XE7 kommt man nicht vorbei, denn nur in XE7 sind die Bugs behoben. Außer denen die immer noch drin sind. ;-(

Zum Vergleich die erste compilierfähige Version für Android war auf meinem Nexus 10 so langsam, dass man nicht mit arbeiten konnte. Mit XE7 ist die Android App um ein vielfaches schneller als auf meinem iPad und immer noch schneller als auf meinem iPhone 5.

Es hat sich also einiges verändert...

Mavarik

**RWarnecke**

Meine Aussage mit den Kompromissen bezieht sich nicht nur auf das designen der GUI sondern auf alles. Für mich ist es immer noch ein Rätsel, wie ich API-Befehle von iOS entsprechend für Delphi umsetze. Bei XCode kann ich den API-Befehl entsprechend anwenden und funktioniert auf Anhieb. Das gleiche ist mit der Windows-API. Hier habe ich eine ähnliche Konstellation. Einfach im MSDN nachschauen, wie der Befehl aufgebaut ist und das ganze entsprechend nach Delphi übersetzen. Das nenne ich einfache und schnelle Entwicklung.

Die genannten Beispiele vermisse ich sehnlichst bei Firemonkey. Wenn ich erst hier und da etwas casten muss und dann noch irgendwo zwischen speichern oder sonst irgendwas machen muss, behindert mich das nur in meiner Arbeit. Ein gutes Beispiel ist die Komponente TLocationSensor. Dieser hat bei mir schon seit XE4 nicht richtig funktioniert. Ich habe lediglich nur die Ermittlung der Geo-Koordinaten von der Komponente abgezogen und den Rest selber berechnet und ausgewertet. Aber es ist ja nicht nur die Komponente, einfach das ganze Aussehen, die oft schon angesprochene Performance der Apps. Eine Delphi iOS App macht einfach nicht das her, was eine XCode App her macht. Das ist zumindest meine Meinung, nach jetzt 4 Versionen von Delphi, womit man iOS und Android Apps erstellen kann.

**kuba**

Zitat von Harry Stahl:

Generell gefällt mir XE7 sehr gut. Der Compiler ist m.E. einer der schnellsten bisher.

Was ich gerade schade finde, sind die immer wieder neuen Bugs von Version zu Version.

Nach stundenlanger Suche habe ich nun herausgefunden, dass jede TDateEdit, welches in einer Windows-FMX-Form liegt, ca. 300 Millisekunden für die Erzeugung braucht.

Bei 4 TDateEdit also ca. 1,2 Sekunden.

Unter XE6 war die Erzeugung nicht messbar.

Böser Bug!!

Das bringt mich gerade auf eine Idee, habe da so ein Problem die TDateEdit Komponente während des OnShow Event mit Werten aus der Regitry zu befüllen (XE2 kein FMX). Mit anderen Komponenten funktioniert alles reibungslos, nach meinen Tests spricht alles dafür dass die Komponente irgendwie nicht "bereit" ist den ausgelesenen Wert zu übernehmen. Wird die Komponente denn erst zur Laufzeit erzeugt ? Ich dachte das passiert schon zur "Entwicklungszeit" wenn die Komponente auf dem Formular plaziert wird. Das muss ich mir nochmal genauer anschauen und werde mal mit Hilfe eines Timers erst nach dem OnShow Event einlesen.

Habe gerade nochmal nachgeschaut, es sind 2 Komponenten TDateTimePicker und TSpinEdit ...

Ach sorry, aber ich glaube das Problem hängt nicht miteinander zusammen, war nur so eine Idee.

kuba

**jaenicke**

Zitat von kuba:

Das muss ich mir nochmal genauer anschauen und werde mal mit Hilfe eines Timers erst nach dem OnShow Event einlesen.

Besser ist dir im OnShow eine Message mit PostMessage zu schicken.
Damit brauchst du keinen Timer und hast dennoch den gleichen Effekt, du bekommst eine Windows Message. Denn der Timer funktioniert intern auch nur per Message WM_TIMER.

Zitat von kuba:

Habe gerade nochmal nachgeschaut, es sind 2 Komponenten TDateTimePicker und TSpinEdit ...

Beliebt sind da eigene Eventhandler, die beim Laden der Werte ablaufen. (OnChange, ...)

**jbg**

Zitat von Harry Stahl:

Bei 4 TDateEdit also ca. 1,2 Sekunden.

Unter XE6 war die Erzeugung nicht messbar.

Böser Bug!!

Das ist ein architektonischer Problem. Das hat man davon, wenn man aus allem und jedem ein Control machen muss. Für jeden Tag im Monat wird ein TTextControl erzeugt, was viel unnötigen Code mit sich bringt. Schon allein das Ausrichten der Controls wird verlangsamt. In diesem Fall ist es aber das Setzen der TTextControl.Text-Eigenschaft, da dort der Style geklont wird, was viel Zeit kostet, da zum Klonen das DFM-Streaming benutzt (missbraucht) wird. Und das DFM-Streaming ist seit der Umstellung von "IsStoredProp" auf Attribute (RichRTTI) noch um einiges langsamer geworden.
Zudem wird der Kalender für 1899 und das aktuelle Jahr aufgebaut, also doppelt.

**Harry Stahl**

Nachdem ich also nun ein mittelgroßes Projekt mit Delphi XE7 für den MAC fertig gestellt habe, muss ich sagen, dass ich es nur mit XE7 so schnell fertig stellen konnte. Denn die ganzen Modifikationen, die man machen muss, damit die Dialoge "MAC-Like" aussehen, das ging mit dem Multiview-Designer enorm viel einfacher, als der bisherige Weg, alles über IFDEFS lösen zu müssen.

Wer Interesse hat, kann sich ein paar Screenshots zum Programm hier ansehen:

http://www.pc-rechnung.de

In Kürze wird noch ein Produktvideo folgen und ein kleines Video für Entwickler in meinem Firemonkey-Videoblog, das hier noch ein paar Erläuterungen geben wird.

Zusammenfassend kann man aber sagen, dass mit XE7 nun vieles einfacher geworden ist und der Compiler ist echt Hölle schnell.