Der Delphi / RADStudio XE8 Release-Thread

[Daniel]

@Harry: Das ist völlig richtig. Nur habe ich auf die Schnelle kein Zertifikat zur Hand und für so ein "Dödel-Projekt" möchte ich auch keines anschaffen. Ich gebe zu, dass es etwas halbgar ist, zur Not belasse ich es bei der Beschreibung und nehme den Download wieder weg.

[Harry Stahl]

Weg nehmen würde ich das nicht, wäre schade drum, da ist es jedenfalls noch 1000 mal einfacher Windows zum "Trotzdem Ausführen" zu bewegen, als in der Registry rumzuwerkeln.

Also bitte da lassen.:thumb:

[Harry Stahl]

Zitat:

Zitat von Harry Stahl (Beitrag 1296538)

Sehr schön: In FMX gibt es jetzt eine sehr komfortable Imagelist und den TSpeedbuttons können nun endlich auch Images aus der Imagelist zugewiesen werden!

Edit: Und beim TButton geht das auch!

Das freut mich deswegen so sehr, weil dann die Konvertierung von VCL nach FMX noch um einiges leichter an dieser Stelle werden dürfte...

Und ergänzen möchte ich, dass jetzt auch die Actions Images bzw. ImageIndex haben und die ActionList mit einer TImageList verknüpft werden kann.

Und noch mal Edit: Auch MainMenu, Popup-Menu können mit einer Imagelist verlinkt werden und die TMenuItems haben ein ImageIndex.

Sehr schön, diesbezüglich gibt es jetzt also (endlich) einen adäquaten Anschluss an die VCL.

Schade: Hints fehlen immer noch. Muss meine HS_FMXHints.pas wohl noch etwas weiter im Einsatz bleiben...

[kaju74]

Moin.

Castalia wurde aber zur XE7-Version ganz schon abgespeckt, wa? Zumindest in der XE8-Trials fehlen da einige Dinge, vor allem die Live-Templates...

Gruß,
Marc

[jaenicke]

Dafür habe ich auf den ersten Blick auch keine der Fehler aus XE7 mehr gefunden, insofern finde ich es besser, wenn die Integration offenbar wirklich sauber mit (vielleicht ja auch nur anfangs) weniger Features gemacht wird. Aufgefallen ist mir das nicht, dass da etwas nicht dabei ist.

[kaju74]

Hast schon recht, wenn es jetzt runder läuft: weniger ist mehr

Gruß,
Marc

[himitsu]

Aber vielleicht kommt es ja noch, also ab den XE9 Enterprise-Lizenzen.

Castalia wurde doch komplett gekauft? Nicht so wie bei AQTime, Documentation-Insight und Co., wo man, nur als Anheizer, eine Miniversion drin hat.

[mkinzler]

Diese hat man ja auch nur lizenziert. Castalia hat man sich, mitsamt dem Entwicker einverleibt. Wie damals VGScene, was ja bekanntlich in FMX eingeflossen ist.

[kaju74]

Zitat:

Wie damals VGScene, was ja bekanntlich in FMX eingeflossen ist.

Und wo seit XE2 immer noch die gleichen Bugs present sind...Ich verstehe es nicht. Wenn
Delphi sooo auf die mobile Schiene getrimmt wird, warum wird dann nicht endlich mal ein
gescheiter Designer entwickelt und die alten Bugs beseitigt? Der Style-Editor hat sich
überhaupt nicht weiterentwickelt, tiefer veschachtelte Elemente eines Layouts lassen sich
im Editor immer noch nicht anwählen, Guidelines fehler auch noch, und und und...

Ich will je echt nicht meckern, aber wo sind bezüglich FMX die großen Unterschiede zu
XE2?

Marc

[himitsu]

Intern hat man schon bissl was umgebaut.

Vorallem Property umbenannt und an den Enums rumgespielt ... drum bekommt man in XE3 ein FMX-Projekt aus XE7 praktisch nicht mehr auf, ohne daß das Layout total zerstört wird.
Nun auch wieder ein paar selbstgemalte Komponenten gegen native Systemkomponenten ersetzt. (wenn ich das richtig verstanden hab)

[mkinzler]

Nichts ändert sich so schnell wie FMX. Ob die Änderungen alle logisch sind oder nicht, steht auf einem anderen Blatt. EMBt kommt mir eher wie getriebene vor, die von Version zu Version hetzten und einfach keine Zeit für die "Kleinigkeiten" wie der Styleeditor haben, da die Konkurrenz und die Hersteller der mobilen Plattformen das Tempo vorgeben bzw. durch Änderungen/Abkündigungen EMBT zu Änderungen zwingen, welche die kompletten Entwicklerkapazitäten "auffressen".

[Darlo]

Zitat:

Zitat von kaju74 (Beitrag 1296609)

Ich will je echt nicht meckern, aber wo sind bezüglich FMX die großen Unterschiede zu
XE2?

Oh, da sind Welten. Insbesondere die Performance hat sich in meinen Augen um paar hundert Prozent verbessert! Abgesehen davon dass man es seit XE5 benutzen kann und es seit XE7 dazu noch Spaß macht ;-)

Zitat:

Zitat von himitsu (Beitrag 1296610)

Nun auch wieder ein paar selbstgemalte Komponenten gegen native Systemkomponenten ersetzt. (wenn ich das richtig verstanden hab)

Und der "native TSwitch unter iOS" oder besser gesagt TSwitch mit ControlType := platform ist richtig gut. Wenn man mal einen gemalten TSwitch und einen "nativen" auf dem iPhone ausprobiert dann sieht man die Welten.

[Sherlock]

Habs hier nirgends gesehen, darum hier mal die Liste der Bugfixes: http://edn.embarcadero.com/article/44358

Sherlock

[kaju74]

Hi.

Ja, okay, es gibt FireUI und jetzt der Multi-Device Preview....mir geht es aber um die "inneren Werte" und wie man mittels der zur Verfügung stehenden Editoren schnell und einfach (= RAD) ansprechende Oberflächen basteln kann. Und "hier" hat sich in meinem Auge nicht wirklich viel getan. Der Editor hängt da echt weit hinterher - leider. Es geht ja in die richtige Richtung, aber einige Unzulänglichkeiten werden einfach nicht ausgemerzt und mir ist schleierhaft, wieso. Nutzt den Design Editor keiner? Wie soll man da in einer großen App vernünftig eigene Designs entwickeln, wenn man permanent Angst haben muss, den kompletten Style zu zerschießen, weil irgendwas auf einmal nicht mehr klappt bzw. falsch in die Datei geschrieben wird, sodaß sich die Style-Datei nicht mehr öffnen lässt? Klickt man einmal zu viel, gibt's ne' Exception und das wars.

Gerade vor einigen Wochen gefunden:

Man designe ein neues Element im Designer mit Layout's und weiteren Subelementen. Für eines definiert man einen Effekt, um z.B. die Fill.Color zu animieren. Über TAnimation.xyz kann man ja jetzt die Animation über den Code starten. Die Methode erwartet dann einen Namen, um per Rekursion das entsprechende Child-Element zu finden. Dummerweise erlaubt der Editor aber nicht die Vergabe von Namen (man kann sie zwar eingeben, diese werden aber nicht übernommen), sondern nur die Definition eines Style-Namens. Die TAnimation-Methoden erwarten aber keinen Style-Namen, sondern einen Komponenten-Namen, der sich aber ja nicht vergeben lässt. Also, muss ein Workaround her.

Oder: Man definiert eine Form ohne Border und setzt ein TScaleLayout darauf. Beim Starten wird dieses Layout aber auf einmal ein paar Pixel in die Breite gezogen, sodass alle darauf platzierten Elemente plötzlich breiter sind, als designed. Die Form hat keiner Margins oder Paddings, und der BorderStyle ist "none". Warum wird also die Form beim Starten auf einmal breiter?

LG,
Marc

[himitsu]

Zitat:

Zitat von Sherlock (Beitrag 1296613)

Habs hier nirgends gesehen, darum hier mal die Liste der Bugfixes: http://edn.embarcadero.com/article/44358

Jetzt muß nur noch jemand der Jira Bescheid geben.

Zitat:

Vorgänge: 109 erstellt und 0 erledigt

Auch wenn Jira noch nix sagt (Status: Offen / Lösung: Nicht erledigt), aber gaaaaaaaanz unten auf der Liste/Artikel ist zur Abwechslung auch mal einer meiner Reports repariert wurden.
Jetzt muß ich mir nur noch den Bugfix kaufen. :thumb:

[Mavarik]

Zitat:

Zitat von Darlo (Beitrag 1296612)

Zitat:

Zitat von kaju74 (Beitrag 1296609)

Ich will je echt nicht meckern, aber wo sind bezüglich FMX die großen Unterschiede zu
XE2?

Oh, da sind Welten. Insbesondere die Performance hat sich in meinen Augen um paar hundert Prozent verbessert! Abgesehen davon dass man es seit XE5 benutzen kann und es seit XE7 dazu noch Spaß macht ;-)

100%ige Zustimmung... Besonders im Android-Bereich, iOS nicht ganz so große Unterschiede auf jeden Fall ein Update "Wert"!

Zitat:

Zitat von Darlo (Beitrag 1296612)

Und der "native TSwitch unter iOS" oder besser gesagt TSwitch mit ControlType := platform ist richtig gut. Wenn man mal einen gemalten TSwitch und einen "nativen" auf dem iPhone ausprobiert dann sieht man die Welten.

Hab ich noch nicht versucht, da ich nicht die nativen-Styles nutze, sondern eigene und da würde es echt doof aussehen...

Wo liegt der Unterschied?

[Der schöne Günther]

Ich denke er meint dass man einfach sieht, ob es "selbst gemalt" oder echte OS-Komponenten sind. Jeder mag das anders wahrnehmen (und ich kenne FireMonkey nur auf Windows), aber man sieht schon auf den ersten Blick ob es "echte" Windows-Controls oder FireMonkey ist. Ränder von Steuerelementen, Textmarkierungen, Hover-Verhalten- Gibt viele Kleinigkeiten wo es auffällt.

Wenn man komplett seinen eigenen Stil macht fällt das natürlich nicht ins Gewicht.

[mkinzler]

Der Unterschied liegt darin, ob man ein Control im Stil eines OS selber malt, oder ob man das Control des OS nutzt ( wie die VCL bei Windows.)

[Mavarik]

Zitat:

Zitat von mkinzler (Beitrag 1296643)

Der Unterschied liegt darin, ob man ein Control im Stil eines OS selber malt, oder ob man das Control des OS nutzt ( wie die VCL bei Windows.)

Ach... Und wie malt iOS die Kontrolls...

[Bernhard Geyer]

Zitat:

Zitat von mkinzler (Beitrag 1296643)

... oder ob man das Control des OS nutzt ( wie die VCL bei Windows.)

Mit VCL Theming malt man aber auch wieder selbst ...

[mkinzler]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1296649)

Zitat:

Zitat von mkinzler (Beitrag 1296643)

... oder ob man das Control des OS nutzt ( wie die VCL bei Windows.)

Mit VCL Theming malt man aber auch wieder selbst ...

Aber nicht komplett. Man verwendet trotzdem dessen Funktionalität und implementiert diese nicht selber.

[mkinzler]

Zitat:

Zitat von Mavarik (Beitrag 1296648)

Zitat:

Zitat von mkinzler (Beitrag 1296643)

Der Unterschied liegt darin, ob man ein Control im Stil eines OS selber malt, oder ob man das Control des OS nutzt ( wie die VCL bei Windows.)

Ach... Und wie malt iOS die Kontrolls...

Das ist ja eigentlich egal, es wird eine Control mit Hilfe des OS erzeugt und dessen Funktionalität gewrappt.

[Mavarik]

Zitat:

Zitat von mkinzler (Beitrag 1296653)

Zitat:

Zitat von Mavarik (Beitrag 1296648)

Zitat:

Zitat von mkinzler (Beitrag 1296643)

Der Unterschied liegt darin, ob man ein Control im Stil eines OS selber malt, oder ob man das Control des OS nutzt ( wie die VCL bei Windows.)

Ach... Und wie malt iOS die Kontrolls...

Das ist ja eigentlich egal, es wird eine Control mit Hilfe des OS erzeugt und dessen Funktionalität gewrappt.

Was willst Du mir erklären? Das iOS Pixel besser malen kann als FMX? Oder schneller? Oder geht es Dir um Abweichungen von 1-2 Pixeln? Oder um die Funktionalität? Zugegeben die Animationen über die Ani-Timer ist nicht optimal...

[mkinzler]

Native Controls benötigen zum Zeichenen weniger Strom ( wie es bei den gewrappten aussieht kann ich aber nicht sagen).
Aber der große Vorteil ist aber, wenn sich das Aussehen durch ein iOS Update ändert, ändert sich das Design des gewrappten Controls mit. Änderungen/Verbesserungen in der Funktionalität könnten auch dazukommen.

[Darlo]

Die Animation beim Switchen ist viel flüssiger und die Einstellung dass bei Checked eine I und bei unchecked eine 0 eingeblendet wird funktioniert auch.

[Mavarik]

Zitat:

Zitat von mkinzler (Beitrag 1296662)

Native Controls benötigen zum Zeichenen weniger Strom

Warum?

Zitat:

Zitat von Darlo (Beitrag 1296666)

Die Animation beim Switchen ist viel flüssiger und die Einstellung dass bei Checked eine I und bei unchecked eine 0 eingeblendet wird funktioniert auch.

Die I/O kann man sicherlich noch implementieren!

[mkinzler]

Zitat:

Zitat von Mavarik (Beitrag 1296670)

Zitat:

Zitat von mkinzler (Beitrag 1296662)

Native Controls benötigen zum Zeichenen weniger Strom

Warum?

Keine Ahnung, aber FMX Anwendungen ziehen Strom ohne Ende. Anwendungen mit nativen Controls weniger.

Zitat:

Zitat:

Zitat von Darlo (Beitrag 1296666)

Die Animation beim Switchen ist viel flüssiger und die Einstellung dass bei Checked eine I und bei unchecked eine 0 eingeblendet wird funktioniert auch.

Die I/O kann man sicherlich noch implementieren!

Kann mann schon, aber warum etwas selber implementieren, wenn die nativen Controls das schon können?

[himitsu]

Das OS kann optimalere Zeichenfunktionen nutzen, wärend Delphi quasi alles durch eine 3D-Engine quetschen muß.

Außerdem muß man da ja praktisch jede Funktionalität selber "nachbauen", welche das OS bereits implementiert hat und vorallem zukünftig implementieren wird.

[Mavarik]

Zitat:

Zitat von mkinzler (Beitrag 1296674)

Zitat:

Zitat von Mavarik (Beitrag 1296670)

Zitat:

Zitat von mkinzler (Beitrag 1296662)

Native Controls benötigen zum Zeichenen weniger Strom

Warum?

Keine Ahnung, aber FMX Anwendungen ziehen Strom ohne Ende. Anwendungen mit nativen Controls weniger.

Zitat:

Zitat:

Zitat von Darlo (Beitrag 1296666)

Die Animation beim Switchen ist viel flüssiger und die Einstellung dass bei Checked eine I und bei unchecked eine 0 eingeblendet wird funktioniert auch.

Die I/O kann man sicherlich noch implementieren!

Kann mann schon, aber warum etwas selber implementieren, wenn die nativen Controls das schon können?

Weil die hässlichen nativen Controls nicht zu meinen passen!

[Daniel]

Seid bitte so gut und gliedert die Diskussion über "Malen auf dem Canvas" aus, das Thema ist ja nicht unbedingt XE8-spezifisch.

[bcvs]

Mal was anderes: Weiß jemand, ob das Appmethod jetzt auch schon auf dem technischen Stand von XE8 ist, oder hinkt das hinterher?

Auf meine Frage dahingehend bei Emba Deuschland habe ich keine Reaktion erhalten.

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1296631)

Zitat:

Zitat von Sherlock (Beitrag 1296613)

Habs hier nirgends gesehen, darum hier mal die Liste der Bugfixes: http://edn.embarcadero.com/article/44358

Jetzt muß nur noch jemand der Jira Bescheid geben.

Hat auch schon zu XE7.1 noch nicht geklappt. Der "Bescheidsager" ist scheinbar noch nicht fertig implementiert...
Im Internen Jira wird alles schon auf Fixed stehen.

[Daniel]

Zitat:

Zitat von bcvs (Beitrag 1296690)

Weiß jemand, ob das Appmethod jetzt auch schon auf dem technischen Stand von XE8 ist, oder hinkt das hinterher?

Das hinkt eine Idee hinterher, binnen 14 Tagen sollte aber auch dort eine vergleichbare Version erscheinen.

[himitsu]

@Bernhard Geyer: Hätte ich diese Liste nicht bis zur letzten Zeile durchgelesen, dann wüsste ich doch garnicht, daß ich mir jetzt den Bugfix (den Ersten von 8, alleine im Jira) kaufen kann und nicht doch lieber noch ein/zwei Jahre warten sollte? :roll:

[Harry Stahl]

Also mir gefällt ja, dass ich im Startbildschirm direkt eine neue Geräteübergreifende Anwendung erzeugen kann, da ich das inzwischen sehr oft benutze. Auch der direkte Link zu den Beispielprojekten ist gut.

Was ich jedoch sehr bedauere ist, dass die Favoriten nicht mehr angeboten werden. Oder habe ich hier irgendwo etwas übersehen?

Wenn die raus sein sollten: Bitte unbedingt wieder einbauen!

[Bernhard Geyer]

Unsere Delphi-Hauptanwendung konnte ich kompilieren.
Update auf eine (Zentrale) Komponente wurde durchgeführt. Alle anderen habe ich mir selbst die Packages erstellt.
Für die Packages mit Prefixes war das ein Klacks. Die Packages die noch die IDE-Version im Dateinamen hatten war es natürlich etwas aufwändiger.

Das Speicherproblem noch nicht gefixt. Habe verglichen mit XE6 noch höhere Speicherverlust beim Compilieren.
Der initiale Speicherbedarf beim Laden der IDE ist geringer.

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1296947)

Der initiale Speicherbedarf beim Laden der IDE ist geringer.

Es sei den Du hast viele Fenster auf... Die brauche komischerweise mehr Speicher in XE8

[BigAl]

Ich habe heute mal die XE8 30 Tage parallel zu meiner XE6 installiert. Das ist schon ziemlich enttäuschend:

Die Hilfe ist ein totaler Rückschritt. Da findet man nichts mehr. Nicht nur dass jetzt alle Teile der Hilfe in eigenen Dateien Verpackt sind, es werden auch meist nur irgendwelche Artikel für C++ gefunden. Sucht z.B. mal das Thema Arrays. Hallo!?! Ich habe Delphi installiert und hätte auch gerne eine Delphi-Hilfe. Die Microsoft Help-Komponente ist von 2002 und wird schon seit Jahren nicht mehr weiter entwickelt. Warum macht man so ein Stuss? Bei den Preisen sollte Embarcadero in der Lage sein ein eigenes Hilfemodul zu entwickeln, dass funktioniert oder zumindest auf eine aktuelle Hilfekomponente zurückgreifen. Das ist einfach nur lächerlich.

Ich bin die Schiene seit Turbo Pascal 3 dabei. Dann über Borland Pascal, Pascal für Windows (ja, gab's auch mal) und dann von Delphi 1 bis Delphi XE6. Hierbei habe ich zumindest jedes zweite Versionsupdate mitgemacht. Im Moment überlege ich aber Delphi zu verbannen. Leider entwickle ich seit ein paar Jahren an einem sehr umfangreichen Projekt, welches ich nicht einfach mal so umstellen kann.

Die Update-Politik ist aber die größte Frechheit und hat mir endgültig den Rest gegeben. Ich soll nun für Bug-Fixes zahlen. Und dann jedes Jahr eine neue Version. Anstelle von Fehlerkorrekturen werden haufenweise neue Features reingepackt. Ich habe hier Fehler, die ich schon vor 5 Jahren gemeldet habe. Die sind nach wie vor drin. Das ist ja wohl der Oberhammer. Wenn ICH fehlerhafte Software ausliefere, dann muss ICH die Korrekturen auch kostenfrei nachliefern. Der Kunde würde mich ansonsten - mit Recht - vor Gericht zerren. Ich hab da heute mal während des Webinars nachgefragt: Updates gibt's nur wenn ein Support-Vertrag abgeschlossen wurde. Frechheit. Die machen sich selbst kaputt.

Das Castalia ist auch eine Sache für sich. Das wurde einfach so in die IDE reingeklatscht wie es vom Entwickler bereitgestellt wird. Man hat sich nicht mal die Mühe einer "sauberen" Integration gemacht. Es wird immer noch das Editorfenster gerendert und anschließend pinselt Castalia "drüber". Das ist schön beim Scrollen am Flackern zu erkennen.

Ich könnte noch seitenweise so weitermachen. In den neuen Versionen sind ein/zwei Features, welche mir das Leben enorm erleichtern würden (z.B. der Umgang mit dynamischen Arrays). Das rechtfertigt allerdings kein Upgrade. Ich werde bei meiner XE6 bleiben und das Ganze einfrieren. Ich hoffe nur, dass die XE6 unter Windows 10 noch problemlos läuft. Ansonsten werde ich wohl nach einer alternativen Sprache ausschau halten...

Gruß
Alex

[Darlo]

Hi Alex,

kann Deinen Frust verstehen. Von XE8 bin ich auch bisschen enttäuscht, war ich aber auch von XE6 ;-). Die Frühjahrs-Versionen sind nicht die dollsten. XE2, 5 und 7 waren jeweils top. XE8 ist ein iOS64 Update das leider für 64 Bit nichtmal alle Dateien enthält.

XE9 wird wieder super, XE8 ist eher ein Hotfix oder Update #2

[fgsoftware]

Zitat:

Auszug aus den Release-Hinweis für XE8

iOS-Simulator für iOS 8.x wird noch nicht unterstützt
Der iOS-Simulator für die neueste Version von iOS (8.x) wird als Zielplattformen für geräteübergreifende FireMonkey-Anwendungen noch nicht unterstützt. Sie können allerdings den iOS-Simulator verwenden, der unter iOS 7 unterstützt wird.

Ist jetzt nicht wahr!!!:( Wenn nicht jetzt, wann denn dann!!! Im Herbst gibts wahrscheinlich iOS 9.