RAD Studio XE7: Was Entwickler davon halten...

[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!!

[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.

[blondervolker]

Guten Abend,

also die zusätzlichen "Schnuckeleien" hätte man schon bei XE oder XE2 usw. reinbasteln können...
In Halle an der Saale wurde damals schon gesagt, dass noch weitaus "MEHR" dazu kommen wird.
Also warte ich noch weiter und vor allem länger ab.
Ich kauf mir auch nicht jedes Jahr eine "Neue Kutsche".
Blöder Vergleich... Aber ich fahre auch nur von A nach B...
Und "Fliegen" kann meine "Kutsche" immer noch nicht.

Mehr wie "Lernen" kann man nicht...
Aber permanent neue "Versionen" heraus zu bringen, mit mehr und noch mehr, finde ich absoluten
Schwachsinn.Ist meine Meinung.
Die sind bis heute zu "Faul" die fetten"KÄFER" zu entfernen.
Und warum nicht?

Ich hab den Eindruck, dass der "Chef" von diesen laden noch schnell etwas für seine "Rente" tun will.
Dann isser "wech".
Unterm Strich sollte ich mal "Schauen" was ich meistens "Entwickle".
Und ein "Universal-Talent" von jeder Version zu sein, kann ich nicht behaupten.Und "Bock" jedesmal alles
zu lesen artet nicht in "Wissen" aus, sondern in ein "Durcheinander".
Denne renns`te nach permanent neuen Komponenten und wirst "ARM".(Arm dran oder Arm ab)


Die meisten Anwender sind doch schon "Froh", wenn die Tastatur im Vordergrund "GRINST".
Aber fehlerfreie Sätze zu bilden...verstehen selbst kaum die "Einheimischen".
Das einzige was gut ist, dass sich die neue Version nicht verbiegen kann.

[schand99]

Zum Wiedereinstieg in die Pascal-Entwicklungsumgebung von Delphi 2006, damals noch von Borland, auf XE5 bzw. XE7 hatten mich die vielversprechenden Werbetexte von Embarcadero bewogen. Eine zum Großteil einheitliche Codebasis für verschiedene Plattformen klingt ja auch ziemlich verlockend.
Die Realität sieht dann leider etwas anders aus: vor allem Programme für Android-Geräte laufen mehr schlecht als recht. Abstürze (App reagiert nicht mehr, oder App wurde beendet) sind Regel und nicht Ausnahme. Würde mich nie trauen eine mit Delphi XE7 erstellte App in den Play-Store zu stellen.
Hoffe dass Embarcadero baldigst ein Update für die meiner Meinung nach nur halbfertige Entwicklungsumgebung bereitstellt.