TMS FNC vs. FMX

[Rollo62]

Das wäre ja genau der Vorteil von FNC:
Wenn FNC "nur" die Basisroutinen nutzt, primitive Shapes und Text, und komplexere Controls "fehlerfreier" daraus erzeugt, und nicht von den Buggy-FMX-Control ableitet.
Dann wäre das die Art stabilere Basis die ich meine.

Natürlich wird es noch hier und da FMX Controls geben, aber genu die Verbindung FNC - FMX sehe ich als kritisch.
Denn das wäre doppelter Code, und wie Mensch72 schön sagte: Der Aufsatz auf dem Aufsatz.

Ausserdem sind wohl die Styles auf der Strecke geblieben, was ich Schade finde, was aber womöglich auch zur gesamten Stabilität beitragen könnte.

Die grundsätzliche Frage ist handelt man sich damit mehr oder wniger Probleme ein.

Prinzipiell finde ich die FNC-Idee auch super, aber ob FMX + Lazarus wirklich gut unter einen Hut zu bekommen sind weiss ich nicht (Namespaces, anonyme Prozeduren, etc.).

Rollo

[Harry Stahl]

Zitat:

Zitat von Mavarik (Beitrag 1384230)

Nutzt FNC nicht die Basis-Routine von FMX und bietet "nur" eine einheitliche Ansteuerung von unter VCL/FMX?

Glaube kaum das hier das ganze Framework für die mobilen Plattformen neu Programmiert wurde, oder?

Ja, das siehst Du grundsätzlich richtig so. Aber in dem Zusammenhang gibt es auch eigne Klassen, einheitliche Events, einheitliche Bezeichner usw., die dann auf allen Plattformen gleich sind. Das wird dann natürlich in der Hauptsache verwendet, um die eigenen TMS-FNC-Komponenten auf allen Plattformen und Compilern einheitlich anzusprechen. Aber man kann das auch nutzen, um eigene Komponenten auf der Grundlage des FNC-Systems zu entwickeln. Dazu kann ich nicht viel sagen, da ich selber keine Komponenten entwickle ("nur" Anwendungen), aber in dem 2. Video-Link den ich oben genannt habe, wird, wie ich finde, sehr verständlich beschrieben, wie man eine plattform-übergreifende FNC-Komponente entwickelt.

Zitat:

Zitat von Mavarik (Beitrag 1384230)

PS.: @Harry: Vielleicht eine Einführung am Sa.

Leider kann ich diesmal nicht zum Delphi-Frühstück kommen. Aber die o.g. Videos können wirklich schon sehr gut vermitteln, worum es geht.

[Harry Stahl]

Zitat:

Zitat von Rollo62 (Beitrag 1384235)

Das wäre ja genau der Vorteil von FNC:
Wenn FNC "nur" die Basisroutinen nutzt, primitive Shapes und Text, und komplexere Controls "fehlerfreier" daraus erzeugt, und nicht von den Buggy-FMX-Control ableitet.
Dann wäre das die Art stabilere Basis die ich meine.

Hierzu ein Hinweis: Die FMX-Primitives, hier also auch die von Dir genannten TShape und TText sind bereits abgleitet von TControl. Ich denke, da wird man auch nicht drum herum kommen.

Zitat:

Zitat von Rollo62 (Beitrag 1384235)

Natürlich wird es noch hier und da FMX Controls geben, aber genu die Verbindung FNC - FMX sehe ich als kritisch.
Denn das wäre doppelter Code, und wie Mensch72 schön sagte: Der Aufsatz auf dem Aufsatz.

Allerdings erleichtert mir das als Entwickler die Sache enorm. Ich muss mir nicht überlegen, wie ich unter der VCL oder FMX das Grid verwende und das auch nicht, wenn ich mit Lazarus, statt Delphi arbeite. Den Source-Code, den ich einmal für eine beliebige Plattform mit Delphi oder Lazarus entwickelt habe, kann ich auf einer anderen beliebigen Plattform mit Delphi oder Lazarus verwenden.

Ich kann "im Notfall" auch wunderbar Delphi und Lazarus-Programme miteinander koppeln. Mal als Beispiel: habe ja nun mein PC-Database von VCL auf FMX portiert und für Windows, MAC und Linux entwickelt. Leider unterstützt FNC das FMXLinux noch nicht vollständig, u.a. den Excel-Import und Export. Allerdings werden alle FNC-Komponenten vollständig unter Lazarus für alle Desktop-Plattformen unterstützt (Anm.: Dafür war FNC - als "Framework Neutral Component" auch gedacht. FMXLinux kam erst sehr viel später).

Daher habe ich mit Lazarus ein kleines simples Linux-Progrämmchen geschrieben, das ich vom Delphi-Hauptprogramm aufrufe, die zu importierende Excel-Datei übergebe und dann in das Lazarus-Grid importiere und anschließend als Datei speichere und dann im Delphi-Programm wieder im FNC-Grid einlese (30 Minuten Entwicklungsarbeit), siehe anliegende Screenshots.

Die FNC-Komponenten sind also auch Datenkompatibel unter den verschiedenen Compilern (und Plattformen). Über den Umweg mit FNC über Lazarus, kann ich also auch unter Linux die volle Programmfunktionalität anbieten, wie unter Windows und MAC. Das bietet mir einfach zusätzliche Optionen, meine Ziele zu erreichen, das ist doch super! Wenn TMS dann später auch FMXLinux bei der ExelIO-Komponente voll unterstützt, brauch ich den Umweg nicht mehr und muss nur in meinem Delphi-Hautprogramm ein IFDEF rausnehmen und 4 Zeilen löschen. So easy!

Zitat:

Zitat von Rollo62 (Beitrag 1384235)

Ausserdem sind wohl die Styles auf der Strecke geblieben, was ich Schade finde, was aber womöglich auch zur gesamten Stabilität beitragen könnte.

Die grundsätzliche Frage ist handelt man sich damit mehr oder weniger Probleme ein.
Rollo

Styles sind nicht auf der Strecke geblieben, denn die Compos haben auch eine Ableitung von TStyledControl. Wenn Du für die jeweilige Komponente die Eigenschaft "AdaptToStyle" auf True setzt, passt sich die Komponente dem VCL- oder FMX-Style entsprechend an.

Falls Du den FMX-Styles nicht traust, die FNC-Kompos haben sehr umfangreiche Möglichkeiten, sich farblich nach Wunsch darstellen zu lassen, da ist man schon sehr flexibel mit. Aber ich habe hier bei den FMX-Styles wieder etwas mehr Hoffnung bekommen, da KSDEV ja nun auch Delphi-Styles für FMX und VCL anbieten (http://delphistyles.com/) und hier auch Fixes für Styles (FM UIPlus) liefern (habe ich mir gestern gezogen).