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

Zitat von kaju74:

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 von himitsu:

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.

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

Sherlock

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

Zitat von Sherlock:

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.

Zitat von Darlo:

Zitat von kaju74:

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 von Darlo:

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?

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.

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

Zitat von 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.)

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

Zitat von mkinzler:

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

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