VCL vs. FMX - Die Frage ist (vorerst) offiziell beantwortet

[Bambini]

Zitat von Lemmy:

Zitat von Bambini:

Nun ja, wenn man sich die Geschichte vom Emba-Ribbon-Control anschaut, sollte man doch gelernt haben.

Wie meinst Du das?

Das gibt es nicht mehr, es wurde einfach mal eingestellt
Was man jetzt per GetIT Package bekommt ist ein ganz anderes Ribbon Control.

[ralfstocker]

20 Jahre VCL sind nicht zu toppen. Da ist FMX noch Jahrzehnte entfernt. Man merkt, das an der Verbuggedheit von FMX. Tausende Dinge, die in VCL reibungslos funktionieren, sind in FMX gar nicht vorhanden. Unser Top-Projekt läuft weiterhin mit VCL.

[himitsu]

Dass die Ribbons einzeln sind, ist schon OK.
Immerhin hätte man sich eigentlich erst von Windows 'ne Lizenz besorgen müssen, bevor man sie im Programm verwenden darf, aber man konnte es ja einfach so draufklicken.

Zitat von Bambini:

Zitat von himitsu:

FMX hat paar nette "Layout"-Komponenten, welche man hätte gern auch in der VCL einbauen können, wenn man sie schon neu erfindet. :cry

Statt dessen gibt es bald so etwas: http://blog.marcocantu.com/blog/2016...r-control.html

Ich meinte mehr sowas wie TLayout, also zum "anordnen" von Komponenten, in einem bestimmten Layout. (nicht das Design der Komponenten)
Und wenn man schon sowas neu erfindet, dann doch bitte in beiden Frameworks gleich benamen und vom Verhalten/Bedienung ähnlich gestalten.

[Codehunter]

Zitat von himitsu:

Und wenn man schon sowas neu erfindet, dann doch bitte in beiden Frameworks gleich benamen und vom Verhalten/Bedienung ähnlich gestalten.

Was der Hauptgrund sein dürfte, weshalb kaum Projekte von VCL nach FMX portiert werden. Allein die Einarbeitungs-/Umlernphase für jahrelange Delphi-Entwickler ist schon ungünstig. Vielleicht war das Ganze auch anders rum gedacht, dass man Eclipse- oder AS-Entwickler zu Delphi locken wollte. Hat aber IMHO nicht wirklich geklappt.

Es macht einen ziemlichen Aufriss, die Zuweisungen umzubiegen. Am Ende dann hat man etwas, das in Usability dem VCL-Vorgänger nicht das Wasser reichen kann. Das hat für mich noch nie Sinn ergeben. Aber zumindest das WARUM dieser abweichenden Benennung kann ich nachvollziehen. Firemonkey ist halt ursprünglich von Leuten entwickelt worden, die aus der Dalvik-Szene kamen und sich mit Delphi nicht wirklich auskannten. Emba hätte aber gut daran getan, in der Anfangszeit nach der Übernahme eine Angleichung durchzuführen. Stattdessen hat man versucht, irgendeinen Mittelweg zu finden um die wenigen damals vorhandenen FMX-Projekte kompilierbar zu halten.

Zitat von Bambini:

Zitat von Codehunter:

Von einem Universalframework ist FMX weit entfernt. Darum die Wahl des Thread-Titels: Die Frage ist im Grunde beantwortet.

Wenn die Frage schon entschieden ist, warum baut Emba die ganzen Jahre am falschen Framework?

Ich habe nirgends gesagt, es wäre das falsche Framework. Ich habe nur gesagt, es wäre spezialisiert für mobile Anwendungen und die VCL auf anderen Gebieten überlegen.

Zitat von Lemmy:

Zitat von Bambini:

Das gibt es nicht mehr, es wurde einfach mal eingestellt
Was man jetzt per GetIT Package bekommt ist ein ganz anderes Ribbon Control.

und was genau hat Embarcadero damit zu tun, dass Microsoft die Lizenzierung der Controls durch Entwickler zurück zieht? Embarcadero scheint daraus gelernt zu haben: Die neuen Komponenten basieren nicht mehr auf den Microsoft Komponenten sondern sind eigene Nachbauten.

Soweit ich das verstehe ist es ohnehin völlig egal, ob man Microsofts Controls einbindet oder auf eigenen Wegen ähnlich/gleich aussehende Controls baut. Microsoft sieht in Ribbons eine Art geschütztes Geschmacksmuster. Daher würde sich die MS-Lizenz auf jegliche Art von Ribbon-artigem Control erstrecken. So richtig durchsetzen konnte sich dieses Bedienkonzept außerhalb der MS-Office-Welt auch noch nicht, trotz mittlerweile fast 10 Jahren seit es Office 2007 gibt. Bezeichnenderweise läuft VisualStudio bis heute im klassischen Menü-Toolbar-Design.

Mich stört daran weniger das neuartige Layout als mehr die Tatsache, dass einige Softwareanbieter ihren Produkten auf Gedeih und Verderb dieses neue Look&Feel überstülpen mussten ohne dabei auch das Bedienkonzept anzupassen. Während bei Office das halbe Frontend umgekrempelt wurde um häufig benutzte Funktionen aus den Tiefen diverser Menüs und Dialoge zu holen, hat man sich bei anderen Programmen darauf beschränkt, die vorhandenen Toolbars irgendwie in Ribbon-Tabs zu quetschen. Herausgekommen sind dabei unnütz verlängerte Klickpfade ohne Mehrwert für den Nutzer.

[uligerhardt]

Zitat von Bambini:

Statt dessen gibt es bald so etwas: http://blog.marcocantu.com/blog/2016...r-control.html

Bin mir nicht im Klaren, was Emba mit solchen Controls will. Das gibt es bestimmt schon bei DevExpress, TMS oder anderen 3rd parties.
Nun ja, wenn man sich die Geschichte vom Emba-Ribbon-Control anschaut, sollte man doch gelernt haben.
Schon alleine für einen Frieden mit den 3rd Party Tool Herstellern.
Delphi hat genügend Baustellen die nur Emba bedienen kann, solche Controls gehören bestimmt nicht dazu.

+1. War auch mein erster Gedanke, als ich es gelesen habe.

[Harry Stahl]

Zitat von Sherlock:

Es gab echt einen Glaubenskrieg? Der muss aber sehr einseitig geführt worden sein. FMX ist noch Lichtjahre von VCL entfernt. Der einzige Vorteil ist die Verfügbarkeit für mehrere OSe, das wars dann aber auch.

Sherlock

Bei dieser Aussage könnte man meinen, Du hättest Dich noch gar nicht mit FMX beschäftigt.

Natürlich gibt es noch mehr Vorteile. Eine kurze spontane Auflistung, was die FMX Komponenten bereits als Standard integriert haben und was die Standard-VCL Kompos halt nicht haben (allenfalls in Einzelfällen per spezieller WinAPI-Calls):

* FMX rechnet Positionsangaben per Floating-Point ist ist damit präziser
* Jedes FMX-Objekt kann mit unterschiedlicher Transparenz dargestellt werden.
* FMX-Objekte können rotiert werden (RotationAngle und RotationCenter)
* Jede FMX-Komponente kann selber als Container dienen
* 3D-Fähigkeit
* Super Bibliothek an Bild- und Anmimationseffekten
* Stufenlose Skalierbarkeit von Komponenten

* Erweiterte Fähigkeiten der FMX-Komponenten im Vergleich zum VCL-Pendant, zB:

Listbox: - Integrierte Searchbox, GroupHeader und Footer
- jedem ListboxItem kann ein Icon zugewiesen werden
- jedem ListboxItem kann ganz einfach durch setzen der Height-Eigenschaft eine unterschiedliche Höhe zugewiesen werden
- jedes ListboxItem hat die Eigenschaft Selectable und eigene Einstellmöglichkeiten für Farbe, Justierung, Font, Wordwrap, usw.

* TGrid: Man kann hier direkt unterschiedliche Arten von Spalten einfügen: Strings, Progress, Date, Time, Image, Currency, usw. Jedes Column hat eine Header-Eigenschaft, wo ich ganz bequem schon im Designer eine Überschrift eingeben kann

* TLang-Komponente: Ganz einfache Möglichkeit, Mehrsprachige Produkte zu erstellen

* TImageList: Icons in mehreren Auflösungen bereit halten, mehr und erweiterte Funktionen, um auf die Images zuzugreifen

* TSpeedButton: WordWrap- und Trimming-Eigenschaften

* TEdit, TMemo: Integrierte Unterstützung für SpellChecker (CheckSpelling)

Davon abgesehen, gibt es eine Reihe von nützlichen Komponenten, die es unter der Standard-VCL nicht existieren, z.B. TComboTrackbar, Farbauswahlkomponenten und Trackbar für Alphawerte, TImageViewer, usw.

Oder die ganze Sammlung unter Formen (Rectangle, Circle, usw.), die PATH-Componente, absolut nützliche TSelection-Komponente, mit der Du ganz einfach Selektionen machen kannst oder darin befindliche Komponenten in der Größe verändern oder an andere Positionen verschieben kannst.

[EWeiss]

Zitat:

Delphi? Ach was - in diesem Forum bin ICH das Maß aller Dinge.

Aber klar das wissen wir doch.

gruss

[Mavarik]

Zitat von Harry Stahl:

* TGrid: Man kann hier direkt unterschiedliche Arten von Spalten einfügen: Strings, Progress, Date, Time, Image, Currency, usw. Jedes Column hat eine Header-Eigenschaft, wo ich ganz bequem schon im Designer eine Überschrift eingeben kann

Sehr gute Auflistung. Vielleicht sollten wir diese Punke mal zusammentragen.

Kleiner Ergänzung:

Das Grid hat ein eigenes Datenmodel, sodass man nicht auf die Idee kommt, das visuelle Control als DataHolder zu missbrauchen.
Durch Austausch der Datenquelle lässt sich in Bruchteilen der Zeit gegenüber einem StringGrid unter VCL - wo ich erst alle Zellen neu im UI Thread befüllen muss - die Ansicht wechseln. Da dies auch gerne in einem Thread passieren kann, ist es viel flexibler und performanter.

[Harry Stahl]

Zitat von Mavarik:

Zitat von Harry Stahl:

* TGrid: Man kann hier direkt unterschiedliche Arten von Spalten einfügen: Strings, Progress, Date, Time, Image, Currency, usw. Jedes Column hat eine Header-Eigenschaft, wo ich ganz bequem schon im Designer eine Überschrift eingeben kann

Sehr gute Auflistung. Vielleicht sollten wir diese Punke mal zusammentragen.

Kleiner Ergänzung:

Das Grid hat ein eigenes Datenmodel, sodass man nicht auf die Idee kommt, das visuelle Control als DataHolder zu missbrauchen.
Durch Austausch der Datenquelle lässt sich in Bruchteilen der Zeit gegenüber einem StringGrid unter VCL - wo ich erst alle Zellen neu im UI Thread befüllen muss - die Ansicht wechseln. Da dies auch gerne in einem Thread passieren kann, ist es viel flexibler und performanter.

Danke, die Auflistung könnte man sicher noch um eine Vielzahl von Punkten erweitern.

Was ich beim TGrid noch ergänzen kann: Per "OnGetValue" werden im TGrid bei der Darstellung einer Zeile die Daten erst dann abgefragt, wenn Sie zur Anzeige gebracht werden. Insofern - abgesehen vom Sinn- ist es kein Problem und mit Null Performance-Verlust möglich, 1 Mio. Einträge im TGrid anzuzeigen und rasant zu scrollen. Im VCL-Grid könnte man das entsprechend selber im OnDrawCell-Event machen, hätte aber dann die ganze Zeichnung des Inhalts selber zu bewerkstelligen (und damit einfach wieder ein Haufen mehr Arbeit).

[Mavarik]

Zitat von Harry Stahl:

Danke, die Auflistung könnte man sicher noch um eine Vielzahl von Punkten erweitern.

Vielleicht unter Deinem Blog? : http://www.devpage.de/blog/firemonkey.htm (FMX = RAD ++ )

Würde immer wenn mit was einfällt Dir schreiben...