Plattformübergreifend - Augenauswischerei ...?

[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

[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 :zwinker:

Mein Profil > Profilbild
Einstellungen&Optionen > Benutzerbild

[jaenicke]

Zitat:

Zitat von TuPas (Beitrag 1531687)

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

[Mavarik]

Zitat:

Zitat von jik (Beitrag 1531657)

Nun meine Fragen an euch:
1. Bin ich meiner Blauäugigkeit aufgesessen und sollte mich doch besser in Lazarus hineinfuchsen?

Delphi und FMX bietet aus meiner Sicht alles was man braucht.
Ich programmiere seit XE8 nur noch FMX und überhaupt kein VCL mehr.

Zitat:

Zitat von jik (Beitrag 1531657)

2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind? Ist offenbar keineswegs selbstverständlich.

Eigentlich reichen die FMX Komponten - Wenn Du etwas anders brauchst, kannst Du (wie bei VCL) eine FMX Komponente als Basis nehmen und damit neue Komponenten erstellen.

Zitat:

Zitat von jik (Beitrag 1531657)

4. Oder würdet ihr bei D5 bleiben, so lange es geht?

Nein - D5 ist gruselig wenn wenigstens D2007 - aber was willst Du mit den alten Zeug?

TMS hat Komponenten die Sowohl für VCL und FMX geeignet sind.

Beispiele für FMX findest Du auf meinen YouTube Kanal. (Und auf vielen anderen)

[Rollo62]

Zitat:

Zitat von Phoenix (Beitrag 1531666)

Web-basierte Technologie ist da tatsächlich das einzige das wirklich 100% überall funktioniert.

...

aber alles was JS/TS ist (React, Vue etc.)

Damit bin ich im Prinzip völlig mit einverstanden, nur JS ist wirklich völlig plattformübergreifend.

Nur leider komme ich jedes Mal, wenn ich wieder etwas Neues/Hybrides austeste, ganz schnell an irgendwelche Grenzen.
Solange man Web-Zentrierte Apps baut, die nicht viel von der Hardware oder von den Mobil-Spezialitäten nutzen, dann mag das OK sein.
Sobald man Location, Background-Modi, Bluetooth, Sensoren, Audio, Mail, SMS, PhoneCall, Mikrofon, SpeechRecognition, usw. usw. usw. braucht,
dann gibt es mit Web-Technologie oft noch mehr Beschränkungen als rein nativ.

Egal ob Flutter, React oder Xamarin, ich finde oft sehr viel ähnliche Beiträge in den Foren dort, wo es genauso wenig Lösungen gibt wie bei Delphi.
Zuletzt hatte ich bei Flutter gesucht, wo geschrieben stand: Ja, geht im Prinzip, da gab es diese OpenSource Library ( allerdings nur ein proof-of-concept, ungepflegt), aber offiziellen Support gab es nicht.
Ok, die Entwicklung geht da natürlich rasant immer weiter, aber ein kompletter No-Brainer ist IMHO keine dieser Technologien.

Das Problem ist ja mehr politischer Natur, wenn der Zugriff durch Google/Apple unnötig verkompliziert und restriktiver gemacht wird, ohne Rücksicht auf Verluste.

Deshalb ist Delphi gar nicht so verkehrt, für solche Anwendungen.
Und bei den ganzen obskuren Problemen, die mir untergekommen sind, wenn ich dann mal über den Tellerrand schaue:
Auch Xamarin, Unity, React, Flutter, NetMAUI, ja sogar XCode und Android-Studio selbst, haben oft die gleichen Probleme an die Hardware zu kommen.

Ich würde mir wünschen, einfach nur eine App mit einem DB-View machen zu müssen, eventuell noch mit REST-API,
aber meistens kommt dann doch noch sehr viel obendrauf.

[jik]

Zitat:

himitsu schrieb: Weil du kein Bild dafür hochgeladen hast
Mein Profil > Profilbild
Einstellungen&Optionen > Benutzerbild

Genau dorthin würde ich gern, aber ich finde es beim Profil nicht (siehe hier) und außer neben Willkommen, xyz finde ich nichts. Seltsamerweise konnte ich früher mal das Bild einfügen, kann es jetzt aber nicht mehr ändern. Und Signatur finde ich auch nicht.

Zitat:

jaenicke schrieb: Ich persönlich finde datensensitive Komponenten überhaupt nicht gut, weil man die Datenebene viel zu fest mit der UI verbandelt.

Bei plattformübergreifend vermutlich schon. Wir hatten uns selbst seinerzeit eine Schnittstelle zu Pervasive (live und SQL) geschaffen mit abgeleiteten Komponenten. Das war auf jeden Fall angenehmer, als Daten und GUI komplett zu trennen. So hatten wir eine Applikation, aber die wurde dadurch etwas krakelig.

Zitat:

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

Meines Wissens ist TVirtualStringTree plattformübergreifend. Aber zum Programmieren ein Horror mit den ganzen Records und Zeigern. Diesbezüglich war die Treelist von Developer Express optimal. Für eine gescheite TreeView würde ich auch gern was zahlen. Ist die von TMS nicht so etwas?

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

[jaenicke]

Zitat:

Zitat von jik (Beitrag 1531697)

Meines Wissens ist TVirtualStringTree plattformübergreifend.

Die von Lazarus wohl ja, inwieweit weiß ich nicht. Und die FMX Version wohl auch, aber die ist noch nicht so weit. Das Hauptprojekt ist rein für Windows.

Zitat:

Zitat von jik (Beitrag 1531697)

Aber zum Programmieren ein Horror mit den ganzen Records und Zeigern.

Seit Generics unterstützt werden braucht man direkt keine Pointer mehr (fand ich allerdings auch nicht schlimm). Und Records muss man auch nicht nutzen. Ich habe die Komponente meistens generisch mit Klassen verwendet. (Vor der offiziellen Unterstützung hatte ich die Generics selbst drüber gebaut.)

Zitat:

Zitat von jik (Beitrag 1531697)

@Mavarik: Hab mir ein Video von dir angesehen. Warum soll man bei plattformübergreifend keinen Code hinter einen FMX-Button setzen?

Weil du unter den mobilen Plattformen keinen länger laufenden Code in einem Buttonklick drin haben darfst. Unter Windows ist das nur unangenehm für den Benutzer, unter Android oder iOS kommst du mit solch einem Code nicht in den AppStore.

[bernhard_LA]

ich hatte die (Sisyphos-)Aufgabe vor einigen Jahren unsere Anwendung auch unter LINUX bereitzustellen. Ca. 1 Mio Zeilen Quellcode alles mit VCL programmiert und keine TestCases.
Die Strategie für Cross-Plattform bei uns:

• GUI Code von BL-Logik Trennen ....
• Code Refaktoring nch MVVM (https://de.wikipedia.org/wiki/Model_View_ViewModel) oder vergleichbaren Ansatz
• beide Plattformen unterstützen über compiler switches ( dann kann man immer auf die lauffähige VCL Version zugreifen)
• testcase einführen wann immer es geht :-)
• zu allen Überfluss haben wir auch 2 DB Interface in der Compiler Switch Option
  Delphi-Quellcode:

  {$IFDEF Framework_ADO }

  und
  Delphi-Quellcode:

  {$IFDEF Framework_Firedax }

Delphi-Quellcode:

uses
  types,
  classes,
  SysUtils,
{$IFDEF FrameWork_VCL}
  vcl.Graphics,
  .....
{$ENDIF}
{$IFDEF FrameWork_FMX}
  FMX.Graphics,
  .....
{$ENDIF}



....

[jik]

Noch einmal ganz herzlichen Dank für die Mühe, die ihr euch für die Erklärungen gemacht habt - das finde ich supernett!

Nun muss ich mich mal in das Ganze einarbeiten, was sehr aufwendig ist (was denn sonst :) ). Noch bin ich mir immer noch nicht ganz sicher, ob es Lazarus oder Delphi 12 wird - auch wenn von vielen Lazarus als Hobbytool gesehen wird. Die Tendenz, mal abzustürzen kommt mir bei Lazarus tatsächlich etwas größer vor. Die jetzt leider nicht zu klärende Frage: Was ist, wenn es wirklich viel Code und Units werden ...?

Bisher habe ich halt alle Energie in die Weiterentwicklung des Paketes investiert und mir wenig Zeit genommen, rundherum zu schauen. Denn alle hie und da unternommenen Versuche haben mich relativ bald verstört. Und auch ich glaube, dass mein geschätztes 5er-Delphi mit seinen 32bit-Programmen irgendwann mal outdated sein wird (so nett ich denke, das Programm trotzdem hingebracht zu haben - nicht supermodern, aber es geht, zumal man selbst die 24 Skins sogar anpassen kann). Beim Mac ist das ja schon vor einiger Zeit passiert: Nix 32bit - basta. Allerdings läuft bei Windows intern so viel auf 32bit, dass ich mich noch einigermaßen sicher fühle. Aber Unicode ist ein großes Thema, denn Autoren, die slawische, griechische oder russische Namen verwenden, sind verärgert, wenn das nicht geht.
Das Dumme ist einfach, dass mehrere Dinge unter einen Hut gebracht werden müssen:

1. Plattformunabhängig wäre schön
2. Unicode sollte sein - ist ja ein Programm für Schriftsteller
3. Eine leistungsfähige TreeView - Developer Express war da super, wird aber selbst bei Delphi nicht für Multiplattform mehr unterstützt. Also TFM? Kann das alles? Sieht mir nicht so aus und ich muss sehen, ob man die Optik schöner bekommen kann (als die Demos). Und TVirtualStringTree kann zwar sehr viel, aber die ganzen Records und Zeiger sind für so viele Grids wie ich habe ein Horror.
4. Zum Glück gibt es den Super-Editor TRichViewEdit und TSRichViewEdit von Serge Tkachenko, der auf D12 und Lazarus läuft - eine Wohltat.
5. Ausgabe des Endprodukts (Buch) des Anwenders als PDF-Datei.
6. Ein leistungsfähiges Ribbon, sonst müsste ich das eigene portieren, was vermutlich das kleinste Übel ist. Denn obwohl TSpkToolbar nett aussieht, scheint es beim Schmalermachen des Monitors die Tabs nicht zu schrumpfen können. TFM kann das zwar, aber laut Demo unkontrolliert (kommt mir vor) und vor allem ist das Fenster beim Ziehen ruckelig. Dafür sind die Styles recht gut durch Einbeziehung der Titelleiste, aber der Rand wird durch ein Pixel schlecht fassbar ...

So fühle ich mich derzeit abends total geplättet vor lauter Lesen und Ausprobieren und bin sehr dankbar für eure fachlichen Erfahrungen und Unterstützungen!

Hier noch ein Screenshot, damit ihr seht, worum es überhaupt geht: 164 Fenster bei rund 240.000 Zeilen Code (ohne jegliche Komponenten)

https://autorenprogramm.com/down/tmp/pw.png