Plattformübergreifend - Augenauswischrei ...?

[Jim Knopf]

Kurz zu meiner Vorgeschichte: Ich arbeite seit 1998 mit Delphi. Wir haben damals mit meiner IT-Firma mit Delphi3 begonnen und sind dann bei D5 stehen geblieben, da danach (nach unserer Ansicht damals) die Griffigkeit verlorenging. Bis heute arbeite ich mit D5 und habe nun in Eigenregie seit zehn Jahren ein großes Projekt am Laufen, Patchwork (https://autorenprogramm.com/), ein Programm für Schriftsteller, seines Zeichens das umfangreichste Autorenprogramm (viel Eigeninteresse dabei, weil ich selbst schreibe). Immer wieder erhalte ich aber Anfragen, warum es das nicht für 'wenigstens' MacOS gäbe - verständlich, weil sich viele Autoren als Künstler sehen und Künstler gerne Mac nutzen.

Blauäugig (und vielleicht zu draufgängerisch) wie ich nun mal mit Neuem bin, habe ich zuerst mal Lazarus ausprobiert. War positiv überrascht, wie ähnlich es D5 ist, aber ... die wichtigsten Zusatzkomponenten für Patchwork sind die von Developer Express, brauche ich in fast jedem der über 70 Formulare, oft mehrere. Die sind leider nicht auf Lazarus portierbar wegen der zu großen/tiefen Windows-Affinität. Der Ersatz wäre die TVirtualStringTree-Komponente. Anscheinend sehr leistungsfähig, aber vergleichsweise extrem aufwendig/umständlich zu programmieren und vor allem so gut wie nicht dokumentiert - wie das leider oft bei kostenfreien Sachen der Fall ist.

Also hab ich mich für D12 entschieden. Denn Delphi 12 ist ja plattformübergreifend und IOS und Android auch noch. Und Embarcadero eine große Firma und es gibt Doku ...
Meine bisherigen Erfahrungen sind - bis auf die Hilfe im Forum - ernüchternd. Und nun fiel mir siedend heiß in der Nacht ein: Selbst wenn es von DevExpress Grids & Co in neu gibt - sind die überhaupt wenigstens MacOS-fähig?? Nein, sind sie nämlich nicht - teures Lehrgeld (D12)?

Vor diesem Post habe ich Artikel zum Thema plattformübergreifend gelesen und heftige Zweifel bekommen: 'Nur VCL', 'FMX nicht brauchbar' und weitere abtörnende Erfahrungen.

Nun meine Fragen an euch:
1. Bin ich meiner Blauäugigkeit aufgesessen und Delphi hilft mir keinen Deut mehr als Lazarus?
2. Vor allem: Wie erkenne ich (ohne es auszuprobieren), ob Komponenten multi-plattform-fähig sind (z.B. TSpkToolbar)? Ist offenbar keineswegs selbstverständlich.
3. Ist das TVirtualStringTree MacOS-fähig (mir graut allerdings vor der Menge an Arbeit)?
4. Sind die Komponenten in Lazarus sämtliche unicode-fähig?
5. Oder würdet ihr bei D5 bleiben, so lange es geht?

Danke für eure Lese- und Antwortszeit. Wäre euch für viele Antworten sehr dankbar, denn es geht um eine große Grundsatzentscheidung, die Mannjahre hinter sich herzieht.

[theo]

1. Kann schon sein!
3. Da Virtualtrees Teil der LCL ist, müsste es so sein. Ich habe allerdings keinen Mac um zu testen, wie gut es funktioniert.
4. Ja

Plattformübergreifende Programmierung geht am Besten, wenn man sie von Anfang an einplant.
Nicht kompatible Komponenten nachträglich herausreißen und durch etwas ganz anderes zu ersetzen ist natürlich wirklich mühsam bis zu dem Punkt. wo man lieber neu anfängt.

[wp_xyz]

/2/ Ohne ausprobieren eigentlich gar nicht. Denn Komponenten, die nominell unter den anderen Plattform laufen, können im Detail viele Unterschiede haben. Als Grobausschluss-Kriterium: Wenn irgendwo in den "uses"-Zeilen die Unit "Windows" steht, stehen die Karten schon mal schlecht... Unter Lazarus kann man das oft durch "LCLIntf, LCLType" ersetzen, aber das geht auch nicht immer.

Konkret zu SpkToolbar: ja, das funktioniert (bis auf kleine Darstellungsfehler an den gerundeten Ecken der Tabs) - gerade auf meiner VM ausprobiert.

/5/ Hmmm... Parallel beides. Ich würde die Anwendung in kleinen Schritten für Lazarus umschreiben, mit der Basis-Funktionalität anfangen und dann sukzessive mehr dazubauen. Muss gar nicht auf Mac sein, geht auch auf Windows - besser natürlich, wenn du jeden größeren Schritt auf dem mac überprüfst. Im Prinzip gibt es im Internet virtuelle Maschinen mit MacOS, so dass man ein unter Windows entwickeltes Programm auf dem Mac prüfen kann. Das mache ich. Ist aber wegen der Unterschiede in der Tastatur und wegen mäßiger Geschwindigkeit für ernsthaftes Arbeiten nicht zu gebrauchen. Wenn du mal Land siehst und sicher bist, dass sich der Aufwand lohnt, führt kein Weg daran vorbei, einen "echten" Mac zu kaufen.

[af0815]

Zu 1 ) sage ich nur - Ohne Worte - das muss ein jeder für sich selbst entscheiden
Zu 2 ) Erstens einmal, was verstehtst du unter Multi-Plattform. Ich gehe davon aus Win-Linux-MacOS. Nur ist das nicht die ganze Wahrheit, es geht um Prozessorplattformen und Betriebssysteme. Weil bei Windows gibt es auch 32Bit Intel, 64Bit Intel, 64 Bit Arm, bei MacOS genaugenommen 68k, PowerPC 6x, PowerPC Gx, div. Intel, Apple Silcon und bei Linux die buntesten Möglichkeiten an CPUs. Dazu kommen noch die verschiedesten Widgetsets. Daher muss man mal den Begriff Multiplattform entsprechend einengen. Und dann hilft dir wirklich nur Recherche und testen.
Ach ja, der fpc kann abenteuerlich viele Prozessoren bedienen und auch viele Plattformen. Bei den Widgetsets, wo es dann in Richtung Lazarus geht wird es dünner. Allerdings gibt es da auch diverse Besonderheiten (wie zB. pas2js Widgetset zeigt)
Zu 3 ) keine Ahnung, du wirst um das Basis Testen nicht herumkommen
Zu 4 ) Da würde ich sagen - ja, wenn es echte von den Lazarus Entwicklern gepflegte Componenten sind. Bei den anderen würde ich maximal die Hand des jeweiligen Entwicklers ins Feuer legen. Da kommt es darauf an ob es eine Entwicklung dafür gab oder nicht. Manche Komponenten sin einfach älter, funktionieren aber trotzdem noch - wieder Testen bleibt einem nicht erspart.
Zu 5) Ja, solange die Tests nicht positiv abgeschlossen sind.

Und Theo hat schon vollkommen recht, bezüglich Mühsal. Aber oft ist es auch besser mal komplett von vorne zu starten und soviel wie möglich zu recyceln. Da wird es aber relativ egal sein ob Delphi oder Lazarus. Wobei du bei Lazarus den Sourcecode immer einsehen kannst. Und somit auch notfalls Komponenten selbst weiterpflegen kannst, falls sie verwaisen. Ich halte externe Komponenten in einem extra GIT immer selbst vor, das mir Projekte in der Industrie, die ich oft über Jahre warten muss, nicht zerstört werden. Auch kann man sich mit GIT und fpcupdeluxe immer sehr einfach einen alten Stand vom fpc und Lazarus restaurieren, wenn man sich die Branch und Commitdaten mit dokumentiert.

[af0815]

Über vieles ist auch schon hier diskutiert worden viewtopic.php?f=55&t=13778 (Generelles zum Umstieg Lazarus)

[Warf]

Das Problem beim Platformübergreifenden Programmieren ist nicht das Entwickeln für andere Platformen per-se. Ich würde mal behaupten 90% des Codes den man schreibt ist Platformunabhängig. Alles was man an Logik schreibt ist mit ziemlicher Sicherheit Platformunabhängig, die Frage ist nur was man für bibliotheken benutzt.

Beispiel, C ist super Plattformunabhängig in dem Sinne das es für jede CPU und Betriebsystemkombination einen C Compiler gibt, deutlich mehr als Pascal, Java, oder eine der Sprachen die dafür bekannt sind Cross Platform zu sein. Das Problem ist, mit nur Logik kann man kein Programm schreiben, bzw. keins was irgendwas sinnvolles macht. Am ende muss man immer irgendwie mit der Außenwelt interagieren, und dafür braucht man Schnittstellen (zum OS, zur Hardware, etc.) und die Sind alles andere als Plattformunabhängig.

Das Ziel von Platformunabhängigen Sprachen ist also weniger einen super tollen Compiler mit 300 backends für jede Platform zu bauen, sondern Bibliotheken bereitzustellen die diese Schnittstellen Abstrahieren. Das Problem ist, dafür müssen die Bibliotheken entsprechend gebaut werden.

Delphi ist von vorne bis hinten auf Windows ausgelegt gewesen, und die VCL spiegelt die Win32 Forms API sehr nah wieder. Das ist toll wenn man Windows Anwendungen schreiben will, aber kann echte Probleme machen wenn man versucht die Programme auf andere Platformen zu porten.

Beispiel, eine Listbox mit Delphi zu befüllen geht so:

Code: Alles auswählen

ListBox1.Items.Add('Item1');
ListBox1.Items.Add('Item2');
ListBox1.Items.Add('Item3');

Das mappt auf die unterliegende Win32 API wie folgt:

Code: Alles auswählen

SendMessage(ListHandle, LB_ADDSTRING, 0, LPARAM(PCHAR('Item1')));
SendMessage(ListHandle, LB_ADDSTRING, 0, LPARAM(PCHAR('Item2')));
SendMessage(ListHandle, LB_ADDSTRING, 0, LPARAM(PCHAR('Item3')));

Hier sind die Instruktionen 1-1 auf die Platform API abgebildet. Aber wie schaut das bei einer anderen Platform aus, z.B. MacOS mit Cocoa (Pseudocode, ich kenn mich mit CocoaPas nicht aus):

Code: Alles auswählen

type
  TMyListProvider = class(NSTableViewDataSource)
  public
    function numberOfRows(View: TNSTableView): Integer;
    function tableView(View: NSTableView; objectValueFor: NSTableColumn; row: Integer): String;
  end;

[...]
  
function TMyListProvider.numberOfRows(View: TNSTableView): Integer;
begin
  Result := 3; // 3 Items in der Liste
end;

function tableView(View: NSTableView; objectValueFor: NSTableColumn; row: Integer): String;
begin
  // Wird für jede Zeile einmal aufgerufen um den Wert auszulesen
  case row of
  0: Result := 'Item1';
  1: Result := 'Item2';
  2: Result := 'Item3';
  end;
end;

[...]

// Benutzung:
begin
  provider := TMyListProvider.Create;
  try
    TableView.dataSource := provider;
    tableView.staticData := True;
    TableView.reload;
  finally
    provider.Free;
  end;
end;

Dabei sollte relativ schnell klar werden warum es nicht so einfach ist eine Komplexe Bibliothek wie die VCL, die explizit für Windows gebaut wurde, auf andere Systeme, die sich potentiell ganz anders verhalten zu porten (tatsächlich da die VCL Listbox intern eine StringList verwendet, ist das gar nicht so das große problem einen provider zu bauen, aber es ist dennoch ein nicht trivialer unterschied).

Das ist tatsächlich auch das Problem mit Lazarus, was die LCL auf andere Platformen Portet. Die LCL orientiert sich an der VCL und ist daher auch sehr nah an der Windows API. Das führt dazu das die LCL bis heute am besten auf Windows funktioniert, und selbst bei den gut funktionierenden Widgetsets wie GTK2 oder QT5 Funktionen Teilweise fehlen, weil sie sich einfach nicht gut abbilden lassen. Dazu gibt es noch ne Menge Widgetsets die einfach nicht im Ansatz voll unterstützt werden wie z.B. Cocoa auf MacOS (da Cocoa deutlich anders aufgebaut ist als Win32, siehe Beispiel oben).
Und selbst da muss man noch sagen, zwar werden GTK2 und QT5 gut unterstützt, es gibt mittlerweile allerdings schon GTK4 (und GTK2 ist offiziell End of Life), und QT6, die auch noch nicht unterstützt werden.

Und das fängt noch gar nicht damit an das die VCL (und LCL) auf die typische Desktop Benutzeroberfläche optimiert ist. Mobile Betriebsysteme funktionieren ganz anders, und die art wie Nutzer damit interagieren ist ganz anders. Deshalb ist Lazarus für Android und iOS auch noch mal ne ganz andere Geschichte.

Deshalb machen viele Sprachen es so das wenn sie eine Benutzeroberfläche anbieten, die auf ganz eigenen Prinzipien basiert, und nicht auf eine Platform API ausgelegt ist. Meist wird diese Oberfläche auch "händisch" gezeichnet, sodass man möglichst unabhängig von der Betriebsystem API ist. Das bekannteste Beispiel hier ist vermutlich das Web, HTML basiert auf geschachtelten Elementen in einem Baum die dynamisch ausgerichtet werden und mit CSS "gestyled" werden. Und tatsächlich funktionieren Websites auf jedem System ziemlich gleich gut, egal ob Windows, Linux, Mac, Tablet, Android Handy oder sogar Smart TV.
Web Technologie ist sehr gut darin Plattformunabhängig zu Entwickeln, da es von Anfang an darauf ausgelegt wurde. Viele Sprachen haben das abgekupfert, so basiert .Nets WPF auf XML und CSS.

Delphi hatte damals mit FireMonkey es so ähnlich gemacht. Statt zu versuchen die VCL cross Plattform zu machen haben sie stattdessen was komplett neues Entwickelt (bzw. eingekauft) was keine OS Formulare benutzt sondern alles mit OpenGL oder DirectX selbst Zeichnet. Damit läuft es garantiert auf allen Systemen gleich gut (bzw. gleich schlecht).

---

Um nun also deine Fragen zu beantworten:

1. Bin ich meiner Blauäugigkeit aufgesessen und Delphi hilft mir keinen Deut mehr als Lazarus?

Wenn du eine Bestehende Software Porten willst sind deine Chancen bei Lazarus besser, denn wie gesagt, Lazarus versucht die LCL auf alle Plattformen zu porten, mit erstaunlichem Erfolg, aber nicht optimal, und es wird immer viel Arbeit sein es cross Plattform gut hinzubekommen.

Delphi ist nur für Cross Platform gut wenn du ein neues FireMonkey Projekt machst, aber weil FireMonkey komplett neu Designed ist, bedeutet das das du was UI angeht Praktisch von vorn anfangen musst.

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

Wenns nicht Dokumentiert ist, dann vermutlich gar nicht. Man würde sich zwar wünschen das jedes Projekt einfach ne Seite oder so hat auf der steht wofür es gebaut/getestet wurde, aber leider gibts das nicht immer.

4. Sind die Komponenten in Lazarus sämtliche unicode-fähig?

Die die Part der LCL sind, zumindest auf den gut unterstützen Widgetsets müssten UTF-8 (nicht "Widestring" bzw. Delphi Unicode!) fähig sein. Bei Drittkomponenten ist das so ne Sache (leider ist Unicode support gar nicht so einfach in manchen Fällen).

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

Auf was moderneres Umzustellen ist vermutlich keine schlechte Idee, vor allem da MS mittlerweile Anfängt Rückwärtskompatibilität zu brechen. Delphi 5 ist aus den 90ern, ich würde nicht drauf wetten das das noch ewig auf den neuen Windows Versionen laufen wird.

---

Zum Schluss noch ein ganz praktischer Tipp für deine Situation. Mit https://github.com/Whisky-App/Whisky kannst du Wine "wrapper" für deine Anwendung erstellen. Damit kannst du praktisch Mac Anwendungen erstellen die Wine, einen Emulator für Windows Anwendungen, mitliefern, mit der du dann Windows Anwendungen ausführen kannst.
Am Ende hast du einfach nur ein .app Archiv, was der Mac Nutzer sich in sein Applications Verzeichnis ziehen kann und mit Doppelklick die Windows Anwendung ausführen kann.
Zumindest früher (damals hieß es noch Darwine) hat das erstaunlich gut funktioniert, und ich hab damit sehr viele Windows Anwendungen auf meinen Mac Portiert.

[Jim Knopf]

Vorerst einmal ganz herzlichen Dank für eure unglaubliche 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, das ich parallel auch installiert habe. Die Kosten sind nicht soo das Problem - jeder muss schließlich von was leben - ich muss also keineswegs alles kostenlos haben.
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)

[Soner]

Wenn ich die Fotos von deinem Programm anschaue, dann Frage ich mich wozu du externe Komponenten brauchst.
Ich würde für "TreeGrid" StringGrid nehmen und daraus "TreeGrid" machen. Ribbontoolbar würde ich mit TNotebook, Panels und andere Controls erledigen. Vorteil ist, dass du dein Programm so machen kannst wie du möchstest. Es gibt keine Beschränkung seitens einer externen Komponente.
Wenn du unbedingt auf das aussehen eines Programms Wert legt, dann schau mal bei BGRA-Controls das Beispielprogramm "bgracontrols\test\test_bgra_ribbon_custom". Das ist auch mit einfachen Controls zusammengebestaltelt und sieht gut aus:

bgraribbon.jpg (21.77 KiB) 5101 mal betrachtet

[Jim Knopf]

Hallo Soner,
wie macht man aus einem StringGrid ein TreeGrid ...? TreeView ist für mich das essenziellste Problem.
Für die Ribbons werde ich vermutlich eh die eigenen Komponenten nehmen, denn TSpkToolbar kann anscheinend beim Schmälerwerden des Fensters nicht einzelne Bereiche schrumpfen. Werde gerne deinem Vorschlag mit den BGRATools nachkommen und sie näher unter die Lupe nehmen. Die sind ja wohl geräteübergreifend, oder?
Das Aussehen ist die Visitenkarte, daran liegt mir, aber vor allem jedem Interessenten, sehr viel. Da machen schon kleine Nuancen viel aus.
Viele Grüße
Martin

[af0815]

Werde gerne deinem Vorschlag mit den BGRATools nachkommen und sie näher unter die Lupe nehmen. Die sind ja wohl geräteübergreifend, oder?
Das Aussehen ist die Visitenkarte, daran liegt mir, aber vor allem jedem Interessenten, sehr viel.

Die BGRATools und alles was davon abgeleitet ist, sind meiner Erfahrung nach, plattformübergreifend. Allerdings können Spezialitäten der Plattform sehr wohl auftauchen, weil zB. BGRABitmap überall funktioniert, die Plattformen aber zum Beispiel verschiedene Anordnungen der Bits/Bytes haben. Für BGRABitmaps ist das kein Problem, das läuft überall, aber wenn man auf einzelne Bytes direkt zugreift zB. bei Bildauswertungen, dann sollte man das berücksichtigen. Bei mir war es so, die Komponente konnte es, nur der Programmierer am Anfang nicht

Und, es ist das meiste OpenSource und die Entwickler sind aktiv. Gerade zB. bei BRGAtools etc. kann sehr viel umgesetzt werden bzw. kann man fragen. Da ist dann aber die Plattform wo der ENtwickler sich aufhält am wichtigsten. Das hast du sicher bei Serge Tkachenko gesehen, wie schnell ein interessierter Entwickler reagieren kann (ja ich habe auch schon Software von ihm mit Source gekauft und auch einige Fragen gehabt).

[Soner]

Hallo Soner,
wie macht man aus einem StringGrid ein TreeGrid ...? TreeView ist für mich das essenziellste Problem.
Für die Ribbons werde ich vermutlich eh die eigenen Komponenten nehmen, denn TSpkToolbar kann anscheinend beim Schmälerwerden des Fensters nicht einzelne Bereiche schrumpfen. Werde gerne deinem Vorschlag mit den BGRATools nachkommen und sie näher unter die Lupe nehmen. Die sind ja wohl geräteübergreifend, oder?
Das Aussehen ist die Visitenkarte, daran liegt mir, aber vor allem jedem Interessenten, sehr viel. Da machen schon kleine Nuancen viel aus.
Viele Grüße
Martin

BGRA-Komponenten verwende ich nicht, ich kenne dieses Beispielprogram nur, weil der Ersteller dieses Beispielprogramms in diesem Forum das gemacht hat und ich ihm einige Tipps gegegen habe. Ich verwende meistens nur Standardkomponenten, und falls ich erweiterungen brauche dann erweitere ich Standardkomponenten für das bestimmtes Programm wie ich in diesem Beitrag gezeigt habe.

wie macht man aus einem StringGrid ein TreeGrid ...?
Mit RowHeights:=0. Ich habe kein Beispiel für TStringGrid, es ist tief in mein Programm integriert, aber für TKGrid habe ich ein Beispiel aus vor vielen Jahren und zur meiner Überraschung ist es ziemlich gut dokumentiert (ich bin Schreibfaul), ich füge es bei. Es ist aber nicht komplett fertig, weil ich zu Lazarus-Standardkomponenten mit Anpassung übergegangen bin. Es ist das selbe Prinzip nur bei TStringGrid muss man die Daten mit "AddObject" an bestimmte Spalte verknüpfen. Mann kann auch bei Lazarus "Grids" auch Summenspalten und Zeilen hinzufügen, ich glaube ich habe es auch hier gepostet, falls du so etwas brauchst sag einfach Bescheid.

Ich habe deine Seite und dein Programmbilder angeschaut, es sieht gut aus, du hast etwas gutes gemacht. Man kann das alles innerhalb eines Monats, wenn man Tag und Nacht arbeitet, wenn das dein Kapital ist musst du ja, mit Lazarus/FPC mit Standardkomponenten nachprogrammieren. Ich würde so vorgehen:
1. Nur Standardkomponenten verwenden, auch Ribbontoolbar. Man kann alles mit Standardkomponenten machen. Vorteil ist. dass du unabhängig bist-
2. Für die Speicherung der Daten würde ich die Datenbank Firebird verwenden. Vorteile sind Suche für den Benutzer einfach und Firebird ist mächtig und sehr einfach zu handhaben. Der Benutzer kann auch dein Programm übers Netzwerk/Internet verwenden, sowohl am Schreibtisch als auch in verschiedenen Computern zu Hause/Garten oder du könntest ein zusätzliche App für Handy/Tablett gegen Entgelt anbieten. Für Handy- und Webprogramm musst du natürlich extra Programm schreiben.
3. Für Html-, PDF-, ExcelExport würde ich Lazreport mit "Addons" nehmen.
4. Ich würde Delphi in die Tonne treten und für immer zu Lazarus wechseln. Am Anfang wirst du wahrscheinlich viel Schimpfen, so wie ich damals. Ich bin zu Qt mit C++, dann Gtk mit C, dann Swing mit Java gewechselt, am Ende wieder zu Lazarus/FPC zurück gekehrt weil es einfacher und schneller ist etwas zu machen. Irgendwann gewöhnst du dich an Lazarus/FPC und wirst nie wieder etwas anders haben wollen. Als ich Windows 11 installierte merkte ich, dass ich seit vielen Jahren kein Delphi mehr gestartet habe und deshalb auf Windows 11 nicht mehr installiert habe.

Ich kenne dein Kundenkreis nicht aber dein Programm hat sehr viel Potential. Wenn ich Author wäre würde es mir Spaß machen am Strand, Schwimmbad oder im Grünen zu legen und dabei zu Schreiben. Und wenn man nach Hause kommt, dann kann man damit am Desktop-Programm weiterarbeiten. Das alles kannst du mit Lazarus, weil ich dieses Vorgehen bei uns für Firmensoftware gemacht habe.

Ich wünsche dir alles Gute und viel Spaß.

[Soner]

Noch etwas, vielleicht solltest du überlegen dein Programm komplett auf "Webapp" zu umstellen.
JavaScript und die HTML-Komponenten sind nicht viel anders als die Komponenten bei Lazarus/FPC, weil ich es verwendet habe und erfahrungen habe. Du könntest Datenverwaltungsteil(Neue Datei/Speichern/Laden) als TfpHtttpServer implementieren und die Anzeige und Bearbeitungsteil als HTML/JavaScript implementieren(siehe JSON).
Ich habe es für meinen Fall untersucht es funktioniert sehr gut, das Beste ist du hast mit einem Schlag ein Programm für alle Platformen, von PC bis Handy und Multiuser.

[fliegermichl]

Ich würde definitiv den VirtualTree verwenden.
Das mit den Records in den Beispielen ist ja nur eine der Möglichkeiten, dem Tree die Daten zur Verfügung zu stellen.

In meinen Programmen halte ich normalerweise alle Daten in Klasseninstanzen und der Tree bekommt lediglich für jede Node die Adresse der jeweiligen Instanz.
Dann habe ich meiner Basisklasse die virtuellen Methoden GetText(Column : Integer) : string und SetText(Column : Integer; NewText : string) spendiert welche in der Basisklasse erstmal gar nichts tun und in den abgeleiteten Klassen entsprechend implementiert sind.

Wenn der Tree Daten für die Anzeige braucht, ruft er das Event GetText mit der entsprechenden Node, Spalte und TextType auf. Das leite ich dann einfach an GetText meiner Klasseninstanz weiter.

Es ist also abhängig davon, in welcher Form deine Daten vorliegen.