Plattformübergreifend - Augenauswischerei ...?

[Rollo62]

Zitat von Phoenix:

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

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

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

@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 {$IFDEF Framework_ADO } und {$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

[jaenicke]

Zitat von jik:

Die jetzt leider nicht zu klärende Frage: Was ist, wenn es wirklich viel Code und Units werden ...?

Bei viel Code sprechen wir von Millionen Zeilen. Bei Delphi gibt es seit der Umstellung auf den LSP zur Codevervollständigung Probleme, wenn man Kreuzbeziehungen zwischen Units drin hat. Das ist zwar sehr unsauberer Code, aber leider weit verbreitet. Wenn du das nicht hast, solltest du in aller Regel mit Delphi in deiner Größenordnung des Codes keine Probleme haben.

Zitat von jik:

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

Die TMS FNC Treeview kann auf den ersten Blick das, was bei dir auf dem Screenshot zu sehen ist. Diese ist plattformunabhängig bis hin zum Web:
https://www.tmssoftware.com/site/tms...k-treeview.asp

Zitat von jik:

4. Zum Glück gibt es den Super-Editor TRichViewEdit und TSRichViewEdit von Serge Tkachenko, der auf D12 und Lazarus läuft - eine Wohltat.

Bei den TMS FNC Komponenten ist auch ein Rich Editor dabei, auch für alle Plattformen. Was der kann, weiß ich nicht.

Zitat von jik:

5. Ausgabe des Endprodukts (Buch) des Anwenders als PDF-Datei.

Auch dafür hat TMS eine plattformunabhängige Bibliothek:
https://www.tmssoftware.com/site/blog.asp?post=377
https://download.tmssoftware.com/dow...ryDevGuide.pdf
Wenn du den TTMSFNCRichEditor verwendest, kannst du den Inhalt auch in die PDF Bibliothek gießen.

Zitat von jik:

6. Ein leistungsfähiges Ribbon

Die TMS FNC Ribbon kann schon viel:
https://www.tmssoftware.com/site/tms...ack-ribbon.asp

[Rollo62]

Zitat von jik:

1. Plattformunabhängig wäre schön
...
4. Zum Glück gibt es den Super-Editor TRichViewEdit und TSRichViewEdit von Serge Tkachenko, der auf D12 und Lazarus läuft - eine Wohltat.

Wenn Du was plattformunabhängiges suchst, kann ich nur die HtmlEditorLibrary empfehlen,
Das kann fast alles, was HTML+CSS auch kann, und Du bist dann gleich auf modernem HTML, wenn es mal für was anderes gebraucht ist.
TRichViewEdit is auch super, aber nur VCL.

[Kas Ob.]

Zitat von Rollo62:

TRichViewEdit is auch super, aber nur VCL.

Just updating your information, TRichView does support them all with Delphi ! (for over a year now)
https://www.trichview.com/features/trichview.html

Code:

Supported FireMonkey platforms: Windows (Delphi XE6 and newer), 64-bit macOS (Delphi 10.3 and newer), Android (Delphi 10.4 and newer), 64-bit Linux (Delphi 10.3 and newer + FMXLinux v1.76 and newer), 64-bit iOS devices (Delphi 10.4 and newer), 64-bit ARM iOS simulator (Delphi 11 and newer)

[IBExpert]

Zitat von jik:

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.

Aus meiner Sicht: Ich arbeite in einem Kundenprojekt seit ca 11 Jahren mit Lazarus, der Lazarus Code hat zwar relativ wenig statische Formulare, weil ich mir schon sehr lange auch in alle Delphi Projekten angewöhnt hatte, alles was geht per code zur Laufzeit zu erzeugen und würde das auch nie wieder anders machen wollen. Das Hauptprojekt hat ca 30000 Zeilen quellcode, den ich selber geschrieben hab.

dbcontrols gibt es bei mir nicht sondern eine über lange jahre selber gebaute Klassenarchitektur, die alles relevante von der db in den Speicher holt, wenn es nicht eh gleich in der db weiterverarbeitet werden soll und wenn was angezeigt werden soll, dann eben ohne den datasource kram damit controls auf dem Bildschirm füllt, damit der anwender das sieht und je nach control auch bearbeiten kann.

Speichern geht dann umgekehrt genau so. Ich hab einige Ideeen in der GUI, die ich früher immer zwangsweise mit Fremdkomponenten gemacht hätte, mittlerweile komplett selber in vorhandene Komponenten integriert oder teilweise auch ganz simple code routine erstellt, die das da auf den screen in scrollboxen komponentenweise erzeugt, was sich aus den daten der datenbank ergibt.

Da eh alles zur laufzeit erzeugt wird, braucht mein code den ganzen overhead nicht, das ich irgendwo in der GUI mir dann zur Entwicklungszeit hinklicken kann und mit pseudodaten wie in treeviews oder sogar mit echtdaten in grids anschauen kann, das interessiert mich nicht. Beim debuggen hoppelt der nicht ständig durch irgendwelche mir unbekannten und unwichtigen Komponentenevents, sondern geht zeile für zeile durch meinen eigenen code.

Mir reicht zu wissen, an der position x ist eine scrollbox, wo der ganze kram dann hinkommt, den ich brauche. Das sind dadurch bei mir zum beispiel panels, labels, edits, checkboxen oder sonstwas für ein kram ich da haben will und die zusammenstellung übernimmmt dann eine sehr einfache beschreibungssprache, die meine stored procedures dann in der datenbank dafür zusammenbaut.
ab 10000 Komponenten musst du ein wenig vorsichtiger werden, aber das lernt man dann schnell, zu optimieren.

Das wird zum Beispiel auch für industrielle Kapazitätsplanung benutzt, bei der horizontal die werktage spalten abbilden, vertikal gruppiert maschine/arbeitsgang usw in teilweise extra spalten kommen, je nach sicht (bzw je nach implementation der sp) und je nach daten kommen dann noch zeilweise extra spalten mit details, die man nur bei bestimmten abrufaufträgen sehen muss, aber nicht immer.

Ich hatte mir aus tradition den wolf gesucht nach brauchbaren Grids oder treeview ähnlichen Komponenten und alleine um zu bewerten, ob die meinen Vorstellungen entsprechen können, diverse stunden oder gar Tage meines Lebens damit verplempert. Am Ende ist es sogar so, das teilweise mein Kunde sich die mühe macht, eine Sicht was er gerne sehen möchte, in excel manuell zusammenklöppelt und ich mir das anschau, um das direkt umzusetzen.

war nie ein Problem, hier und da mal extra neuer code weil auf bestimmten komponenten extra hints anzeigen zeigen, klicks darauf bestimmte aktionen oder redirects machen sollte, farben zellenweise passend sein müssen, auslastungen mit mini extra linie dargestellt werden usw. Manchmal zeigte er mir Funktionen, die er aus anderer Software kannte und gut fand und wenn ich die dann auch gut fand, oft schneller als ich selber dachte in meinen code integrierte, ohne irgendjemand fragen zu müssen, ob der das irgendwie in seine eh schon zu komplizierten Komponenten einzubauen.

Das Projekt lief ca 3-4 Jahre als reine win32 Anwendung und anfänglich war lazarus schon wirklich einigermaßen instabil, hat aber bis heute den vorteil, das es im vergleich zu Delphi sauschnell startet. Seit mindestens 5 Jahren ist die lazarus IDE aber sehr stabil und lass dich nicht abschrecken von irgendwelchen "Oppa erzählt vom Krieg ...." Berichten von Leuten, die vor x Jahren das mal 10 minuten probiert hatten und scheisse finden, weil instabil. stimmt nicht!

Ich hatte dann mal aus neugier den Crosscompile auf win64 gemacht und das ganz in der win64 IDE geladen (die es bis heute von delphi ja nicht gibt) und das lief ohne jede sourcecode Änderung. Ein Mac hatte ich eh noch rumliegen, lazarus installiert und auch da dann den Quellcode ausprobiert, dabei ergaben sich ein paar visuelle dinge, die aber schnell beidseitig für win und mac in den code gingen und schon lief das auch da ohne Einschränkung. Nun stand noch Linux auf dem Plan und siehe da, lazarus IDE auf Ubuntu lief der Quellcode dann auch sofort. Es gab damals auch crosscompile varianten für mobiles, das halte ich aber bis heute für begrenzt relevant, weil auf mobile devices mach ich immer alles als Webapplikation (und zwar mit pas2js oder komplexeren kram mit tms webcore, was beides mit lazarus funktioniert) und hab keine Lust warum man binaries an die appstores verteilen sollte um die dann irgendwann aufgrund von deren Restriktionen nicht mehr einsetzbar zu haben oder von vornherein abgelehnt werden, was man aber erst einige tage nach upload erfährt.

Und ganz nebenbei: versuch mal mit jemand der Ahnung von der Materie Delphi IDE Sourcecode hat, im Delphi Umfeld in Kontakt zu kommen, der 1. deinen reproduzierbaren Fehler versteht und 2. diesen dann auch noch selber vor deinen Augen im Debug Modus mit der IDE nachzuvollziehen kann , um dann relativ schnell einen möglichen Bugfix zu diskutieren, der dann oft schon am selben abend im trunc umgesetzt ist. Passierte mir mit Michael von Canneyt und Mathias Gärtner schon auf diversen Lazarus Konferenzen.

Früher gab es solche Namen auch im Delphi Umfeld, die man in USA auf Konferenzen treffen konnte, das war aber im letzten Jahretausend. Mir ist da kein einziger mehr bekannt, der da nicht nur als Tempeltänzer wie Jim McKeeth auf seinen sessions irgendwie scheinbar selber keinen Zugriff auf die IDE Sourcen hat. Nun denn, er ist ja auch schon geschichte bei emba, wie so viele ...

Ich für mein Teil betrachte Lazarus definitiv nicht als "Hobbytool", weil ich damit sicherlich schon einige tausend stunden selber gearbeitet habe und da zu sehr guten Stundenlöhnen. Und wenn du in anderen Foren fragst ist ja auch Delphi nur Hobbykram ... Ist beides de fakto mumpitz aus meiner sicht ...

[dummzeuch]

Zitat von bernhard_LA:

Delphi-Quellcode:

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



....

Diese ifdefs kann man im Prinzip auch durch unit aliases oder unit scope names ersetzen. Dann bleibt der Code lesbarer. Allerdings ist dann evtl. nicht mehr ganz so gut sichtbar, welche Unit jeweils vewendet wird.