Plattformübergreifend - Augenauswischerei ...?

[QuickAndDirty]

Ich weiß nicht wer davon überzeugt ist das FMX nicht brauchbar wäre... Ich finde es besser als die VCL Und habe Apps und Programme für Windows, Android und IOS mit FMX geschrieben. Das geht alles an sich richtig gut.

Lazarus ist auch sehr schön fürs Hobby.

Du wirst kein VCL Projekt mit 70 Formularen auf Android und IOS portieren , es sei denn du hast dich an eine strikte Trennung von Oberfläche und Geschäftlogik gehalten. Dann sollte es kein problem sein die Oberfläche auszutauschen und eine FMX Oberfläche gegen die Geschäftslogik zu binden.
Es steht auch noch zu bedenken, dass du evtl. sowieso neue Formulare designen willst, denn große Auflösungen machen das evtl . notwendig...dann kannst du bei der Gelegenheit gleich zu FMX wechseln.

[himitsu]

Es gibt halt auch ein paar Fallstickte.

Normal hat FMX alle viele System-Komponenten so in etwa nachgebaut.
* nicht nachgebaute Funktionen fehlen dann natürlich
* nativ haben z.B. ScreenReader ein Problem damit, weil für sie diese "Delphi"-Komponenten nicht existieren (gibt es aber teilweise auch eine API zum Nachrüsten, damit "viele" / nicht alle Reader die Infos hintenrum bekommen)
* gibt es ein altes/neues Windows, mit einem anderen Style, dann sieht dein Programm "alt" aus, weil es ja seinen "eigenen" FMX/VCL-Style mitbringt
* ebenso, wenn Windows oder Zusatzprogramme neue Funktionen für eine Komponente nachrüsten, welche die Delphi-Komponente noch nicht kennt
* * z.B. Shortcuts für Smilies/Sonderzeichen, gewisse Eingabeeditoren, Live-Übersetzungen, Sprachsteuerung usw.
* ...

Drum gibt es für einige Komponenten auch die Möglichkeit die native Komponente zu nutzen, welche dann von Delphi über die Form (3D-Zeichenfläche) gelegt wird.

[jik]

Zwischenantwort(-status) neben großem Danke, weil mich eure Posts wirklich weiterbringen:

1. Habe ich so von den TMS-Komponenten erfahren, die denen von Developer Express recht ähnlich zu sein scheinen, und die gibt es für FMX - klingt gut
2. Ich möchte die Anwendung ohnehin großteils neu erstellen und mit einer Mini-Version für den kleinen Einstieg beginnen. Also ist direktes Portieren kein Thema außer vielen Funktionen
3. @QuickAndDirty: Wenn, dann wird es auf Android ohnehin nur eine Light-Version geben, schon allein des begrenzten Platzes wegen
4. Auf D5 würde ich schon von wegen 32bit und kein Unicode ohnehin nur als letzte Notlösung bleiben

Und dann doch noch schnell eine Frage: Warum wird mein zwar vorhandenes Profilbild nicht angezeigt und ich kann es auch nicht ändern und auch keine Signatur eingeben. Muss ich mich noch eigens wo anmelden?

[TuPas]

Hallo jik,

ich hatte mir auch mehr Cross-Komponenten beim Kauf der D12 erhofft.

Wenn man im Designermodus mit der Maus auf die Komponenten zeigt wird eine Sprechblase mit den Unterstützen Plattformen angezeigt.

Mir fehlen für eine komfortable Cross-Entwicklung die Datenbankunterstützungen bei Eingabe-Elemente und Grids.
Nicht umständlich über irgendwelche TStringGrid oder so, das langweilt mich, wenn man die VCL-Schiene kennt.

Jetzt habe ich die Enterprise-Version gekauft und muss entweder viel selbst Hand anlegen um Elemente zu programmieren oder ich kaufe wieder kräftig irgendwelche Drittanbieter-Elemente.

Meine persönliche Erfahrung ist aber, eher die Module kapseln, so dass man das UI stark von dem Rest trennt und dann so nativ wie möglich das UI programmiert um auch wirklich das jeweilige UI und die Konnektivität des jeweiligen Betriebssystems voll auszunutzen (MVC Model).

Ein paar Tests habe ich mit FMX schon gemacht mit einer Anwendung, die auf Win, iOS, Android und macOS läuft. Aber so richtig haut es mich vom Handling her noch nicht vom Hocker.
Aber ich bin noch in der Antastphase - das kann sich also durchaus noch geben.

BTW ... ich muss über GetIt jetzt mal den FastReport VCL und FastReport FMX installieren und sehen, wie brauchbar der ist.

Viel Erfolg jedenfalls bei Deiner Portierung - und berichte bitte.


Gruß

TuPas

[jaenicke]

Zitat von TuPas:

Mir fehlen für eine komfortable Cross-Entwicklung die Datenbankunterstützungen bei Eingabe-Elemente und Grids.

Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt. Insofern vermisse ich diese auch nicht bei FMX. Dort gibt es dafür aber auch Databinding, wenn man es denn unbedingt nutzen möchte.

Eine wirklich gute Gridkomponente vermisse ich aber bei FMX wirklich sehr. Da kommt man um einen Kauf einer guten Komponente nicht herum, wenn man diese benötigt. Mir gefällt die von TMS schon gut:
https://www.tmssoftware.com/site/tmsfncuipack-grid.asp
Aber für eine plattformübergreifende TVirtualStringTree mit auch nur annähernd der Funktionalität der VCL Version wäre ich bereit einiges zu zahlen (und ich denke einige andere auch).

[TurboMagic]

Zitat von jaenicke:

Zitat von TuPas:

Mir fehlen für eine komfortable Cross-Entwicklung die Datenbankunterstützungen bei Eingabe-Elemente und Grids.

Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt. Insofern vermisse ich diese auch nicht bei FMX. Dort gibt es dafür aber auch Databinding, wenn man es denn unbedingt nutzen möchte.

Eine wirklich gute Gridkomponente vermisse ich aber bei FMX wirklich sehr. Da kommt man um einen Kauf einer guten Komponente nicht herum, wenn man diese benötigt. Mir gefällt die von TMS schon gut:
https://www.tmssoftware.com/site/tmsfncuipack-grid.asp
Aber für eine plattformübergreifende TVirtualStringTree mit auch nur annähernd der Funktionalität der VCL Version wäre ich bereit einiges zu zahlen (und ich denke einige andere auch).

Für das VST gibt's dort im Bugtracker eine Diskussion. Da wollte mal jemand was machen.
Details siehe dort.

[Rollo62]

Zitat von jaenicke:

Eine wirklich gute Gridkomponente vermisse ich aber bei FMX wirklich sehr.

Ich habe mir vor kurzem die Steema TeeGrid Komponente angeschafft.
Die scheint alles das zu haben, was ich brauche und ist nicht gleich so ein DevExpress oder TMS Monster.
Ich teste noch, bin aber bis jetzt schon überaus zufrieden damit, denn das füllt genau die Lücke zwischen TStringGrid und TMS/DevExpress.

Die würde ich auf jeden Fall empfehlen, auch weil die Anschaffung preislich keine große Hürde darstellt.

[jik]

Zitat von Rollo62:

Ich habe mir vor kurzem die Steema TeeGrid Komponente angeschafft.
Die scheint alles das zu haben, was ich brauche und ist nicht gleich so ein DevExpress oder TMS Monster.

Danke für den Hinweis. Darf ich dich gleich was fragen?
1. Zwar scheint das Grid auch Unterknoten haben zu können, aber nur eine oder mehrere Ebenen? EDIT: scheints sie auch zu können
2. Grafiken im Header möglich?
3. Spalten mit Checkboxen und/oder Grafiken möglich?
4. Weil VCL dabeisteht: Plattformübergreifend ...? EDIT: Habs schon gesehen: ja

[himitsu]

Im FMX geht es mit den hauseigenen Komponenten eh nur über die LiveBindings.
DB-aware Komponenten, wie man sie von der VCL kennt, sind dort out.




Weil du kein Bild dafür hochgeladen hast

Mein Profil > Profilbild
Einstellungen&Optionen > Benutzerbild

[QuickAndDirty]

Zitat von himitsu:

Im FMX geht es mit den hauseigenen Komponenten eh nur über die LiveBindings.
DB-aware Komponenten, wie man sie von der VCL kennt, sind dort out.

Oh Ja!
Man kann FMX sehr gut ohne Livebindings benutzen und das habe ich auch so gemacht.
Aber die DB Anzeige, Manipulation und Navigation muss man dann selber programmieren,
was aber kein Beinbruch ist, denn Firemonkey ist ein wirklich Komfortables werkzeug.

Allerdings bin ich auch irgendwie ein Fanboy was viele Dinge in bezug auf FMX angeht!
Außerdem bedeutet das Nutzen von FMX und das Verzichten auf VCL und native Windows32 Komponenten,
dass wir Microsofts Philosophie was native Oberflächen betrifft folgen.
Quote von Bard

Zitat:

Ab der Version Office 2013 verwendet Microsoft Office keine nativen Windows-Komponenten mehr. Die vorherige Version, Office 2010, verwendete noch einige native Windows-Komponenten, wie z. B. das Dialogfeld "Drucken" und die Symbolleiste "Standard". In Office 2013 wurden diese Komponenten durch eigene, von Microsoft entwickelte Komponenten ersetzt.

Der Grund für diese Umstellung war, dass Microsoft Office eine einheitliche Benutzeroberfläche für alle Plattformen bieten wollte. Dazu musste Microsoft die Abhängigkeit von nativen Windows-Komponenten aufgeben, die sich von Plattform zu Plattform unterscheiden.