Da ich kürzlich in einem anderen Thread gemeckert habe möchte ich doch lieber mal nachfragen.
Über die Inkompatibilitäten zwischen VCL und FMX weiß ich bescheid (TPosition, Text, OnChecked, Checked IsChecked ...).

Ist es möglich ohne mehrwöchigen Aufwand ein Projekt mit rund 120.000 Codezeilen und 3rd party Tools nach FMX zu portieren?
Hier wären VirtualStringTree und die JEDIs die Spitzenreiter. Der Rest, das sind nur kleine Komponenten.

Wenn Du Logik und Darstellung sauber getrennt hast, besteht zumindest eine Chance, ansonsten sehe ich eher schwarz. Die VCL-Komponenten kannst Du aber in jedem Fall vergessen, Du müsstest dann auf FMX-Pendants ausweichen, sofern vorhanden.

Zitat:

Die VCL-Komponenten kannst Du aber in jedem Fall vergessen, Du müsstest dann auf FMX-Pendants ausweichen, sofern vorhanden.

Also ist das schon einmal vollkommen aussichtslos. Danke.

aussichtslos ist der falsche Ausdruck, es macht nur etwas (Hand)Arbeit und kostet etwas Geld für gute Tools und alle Lizenzen der Vor&Ist Versionen:

http://www.midaconverter.com/
http://www.shareit.com/product.html?productid=300669902

Dazu noch das kleine Tool unseres Harry Stahl hier, dann ist sowas mit etwas manueller Arbeit beherrschbar... "OneClick-AutoConvert" klappt selten zu 100%.

Ich portiere immer StepByStep und aktualisiere zuerst die VCL Version auf (neue) Komponenten, welche es sowohl für VCL als dann auch FMX gibt.
Besonders bei DB Komponenten und "alten" VCL Ständen hat sich bewährt, da zuerst auf UniDAC umzustellen. (ist in ProLizenz besser und günstiger wie FireDac)
Reports und Charts machen die meiste Arbeit, wenn man noch nicht die ProVersionen von FastReport, TeeChart oder TMS eingesetzt hat.

Grobe Schritte:
- altes Delphi < D2007 wird zuerst auf Delphi2007 als letzte NonUnicode Version hochgezogen
- als was noch an Fremdkomponenten in D2007 drin ist auf UniDac, TMS, Jedi, Fastreport, TeeChart umstellen
- wenn VCL-Programm unter D2007 wieder läuft, dann auf aktuelles Delphi 10.0/10.1 zunächst als VCL UniCode Variante hochziehen
- wenn VCL-Programm unter D10.x wieder läuft, dann den MidaConverter und das Tool von Harry Stahl anwenden
- Versuchen durch anfängliches auskommentieren schnell eine erste übersetzbare FMX-Version zu erhalten
- StepByStep die Funktionalität wieder komplett hineinnehmen und "testen"

=> oder jemanden mit Erfahrung fragen, ob er gegen Geld so eine Konvertierung für das Projekt anbietet

Die Frage ist auch welche Plattform du unterstützen willst. Wenn es erstmal nur Windows ist kannst du in gewissem Masse auch VCl und Fmx mischenn (offizell nicht unterstützt, mache ich aber in einem Projekt ohne Probleme).
Würde als erstes die Trennung zwischen UI und Logik überprüfen und ggf. verbessern. Wenn das fertig ist Gui in FmX neu bauen. Hatte vor Jahren noch parallel entwickelt, Sowohl VCL wie FMX Oberfläche. Heute benutze ich VCL nur noch mit Quickreport und Fastreport.

Habe mich gerade erkundigt und VirtualStringTree gibt es nicht für FMX. Die Jedis bestimmt auch nicht.
Da ich davon eine ganze Menge nutze (Jedis nur Code, kein VCL), kommt ein Wechsel erstmal definitiv nicht in Frage.

Zitat von SneakyBagels:

Habe mich gerade erkundigt und VirtualStringTree gibt es nicht für FMX.

Das ist richtig. Da muss man schon etwas Geld in die Hand nehmen um etwas ebenbürtiges zu bekommen. Ich kann davon ein Lied singen.

Zitat von SneakyBagels:

Die Jedis bestimmt auch nicht.
Da ich davon eine ganze Menge nutze (Jedis nur Code, kein VCL), kommt ein Wechsel erstmal definitiv nicht in Frage.

Die JCL hat mit VCL oder FMX nix am Hut. Wenn du keine der visuellen Komponenten benutzt, funktioniert das mit FMX genauso wie mit VCL.
Wenn du damit andere Plattformen meinst, das ist natürlich richtig. Da gibt es keine JCL.

Da ist dann die Frage was du davon wirklich brauchst.

Alternativ wäre auch die Möglichkeit die VCL-Anwendung so zu lassen wie sie ist und einfach als Webanwendung bereitzustellen. Geht dann auf mobilen Plattformen zwar nur online, funktioniert aber auch mit TVirtualStringTree.

Zitat von SneakyBagels:

Da ich kürzlich in einem anderen Thread gemeckert habe möchte ich doch lieber mal nachfragen.
Über die Inkompatibilitäten zwischen VCL und FMX weiß ich bescheid (TPosition, Text, OnChecked, Checked IsChecked ...).

Ist es möglich ohne mehrwöchigen Aufwand ein Projekt mit rund 120.000 Codezeilen und 3rd party Tools nach FMX zu portieren?
Hier wären VirtualStringTree und die JEDIs die Spitzenreiter. Der Rest, das sind nur kleine Komponenten.

Es ist ein wenig schwierig die Frage zu beantworten, da nicht klar ist, ob die konvertierte Anwendung dann später auch unter MAC/OS (und evtl. FMXLinux) laufen soll, oder "nur" Windows unterstützt werden soll.

Dann wäre auch noch relevant, wieviele Forms Du in Deinem Projekt hast.

Also bei mehreren Plattformen und Forms > 50 würde ich sagen, brauchst Du schon mindestens 1-2 Wochen (Vollzeit-Arbeitstag unterstellt), wenn Du Dich schon in FMX auskennst. Hast Du wenig Erfahrung, verdopple die Zeit mindestens.

Ich kenne das VirtualstringView nicht und nutze auch die Jedis nicht, insofern kann ich nicht beurteilen, was es da gibt bzw. verwendet wird, was man evtl. nicht oder nur mit größerem Aufwand auf FMX übertragen kann.

Generell würde ich auch nicht bei der Frage der Konvertierung mit dem Ansatz rangehen, was für "Spezial-Komponenten" habe ich unter VCL und welche gibt es vom gleichen Hersteller evtl. schon unter FMX.

Hier würde ich mir eher prüfen, was muss das Programm an Eingabe- und Ausgabefunktionalitäten abbilden können und was bietet der Basis-Satz von FMX hier? Generell bietet der Basis-Satz schon enorm viel, sehr viel mehr als die VCL und man kann sich sehr leicht eigene "Komponenten" mit erweiterten Fähigkeiten bauen.

Wenn der Basis-Satz nicht reicht, kann man schauen, was für ein Ersatz in Frage kommen könnte. So bietet z.B. TMS einige sehr gute FMX-Komponenten an, auch z.B. eine sonst schwer zu ersetzende Komponente für RTF-Text (den RichtEditor) und auch eine leistungsstarke TreeView-Komponente (http://www.tmssoftware.com/site/tmsf...eview#features).

Zitat:

So bietet z.B. TMS einige sehr gute FMX-Komponenten an, auch z.B. eine sonst schwer zu ersetzende Komponente für RTF-Text (den RichtEditor) und auch eine leistungsstarke TreeView-Komponente (http://www.tmssoftware.com/site/tmsf...eview#features).

Darauf kann ich schon antworten, dass mir 175€ dann doch ein bisschen zuviel sind und ich dann lieber noch ein paar Jahre warte, bis es freie FMX-Komponenten gibt.

wenn ein ConvertToFMX-ToDo für "ein Projekt mit rund 120.000 Codezeilen" keine sagen wir 1000€ Investition in Tools plus 4000€ für einen Monat Zeitaufwand/Lohn verfügbar bekommt, möchte ich nicht da wo du bist arbeiten. Selbst privat wäre mir meine ersparte Freizeit in dem "Projektgrößen"-Rahmen so um 500€ wert.

Sofort verfügbar, voll dokumentiert und nen Anbieter der sich kümmert... ich mag sowas und nehme daher wenn es geldmäßig irgendwie gerade noch vertretbar ist lieber wenige große(=teure) kommerzielle !AllInOne! Comp-Packs ala TMS oder DevArt, als das ich auf Opensource sachen warte oder mir da zig Sachen zusammensuche und das Stückwerk beim nächsten Update von Delphi wieder ewig braucht bis (wieder) alles auf aktuellem Stand verfügbar.

Gerade bei FMX ist die Entwicklung von Delphi noch sehr dynamisch mit schon vielen Breaks und harten Änderungen seit XE2... bei VCL geht heute noch fast alles wie/von Delphi2007... da kann man notfalls auch lange mit unsupportetem Alt-Source weitermachen. Bei FMX geht das in die Hose!
-> wer Geld für eine ProLizenz mit FMX ausgibt, muss auch das Geld für die passenen Tools plus aller JahresUpdates haben und planen, sonst ist es FMX seitig rausgeschmissenes Geld und verlorene Arbeitszeit/Freizeit