Firemonkey-Desaster

[Insider2004]

Wie fast jeder bereits bemerkt hat, ist das FMX-Interface nicht kompatibel zum VCL-Interface. D.h. VCL-Programme können nicht in FMX verwendet werden. Begründet wird dies von EMBA-Seite damit, dass das VCL zu stark an die Win-API gebunden ist und der ganze Code nicht portierbar ist.

Blöde Frage: Warum schafft es Lazarus, ein einheitliches Interface anzubieten? Programme sind fast ohne Änderungen auf allen Plattformen lauffähig. Stattdessen werden bei EMBA wieder 2 verschieden Frameworks entwickelt und gepflegt, die nichts miteinander gemein haben.

[Bernhard Geyer]

Was soll diese absolut negative aussage wieder.

Sehr wohl kann man VCL und FMX (in gewissen Grenzen) miteinander mixen. Selbst auf einem Formular ist (soll) das möglich (http://stackoverflow.com/questions/7...cl-application) sein.

Jedoch wird das von Embaracadero nicht offiziell unterstützt. Und mit der Aussage der Platformabhänigkeit haben sie voll recht. Mit der VCL.NET haben sie ja schon mal Schiffbruch erlitten. Schau dir mal die (nicht Lazarus-Kompatiblen) Komposammlungen so an wie stark diese Teilweise auf die Win32-API aufsetzen. So wäre ein "portable" VCL mit sehr großen Umbauarbeiten/Hacks in vielen Komponenten verbunden die man bei einer strikten Portablen Ansatz nicht hat.

[Insider2004]

Ich rede nur vom Interface.

[Bernhard Geyer]

Was genau meinst du in diesem Fall mit Interface.

[schöni]

Zitat von Insider2004:

Wie fast jeder bereits bemerkt hat, ist das FMX-Interface nicht kompatibel zum VCL-Interface. D.h. VCL-Programme können nicht in FMX verwendet werden. Begründet wird dies von EMBA-Seite damit, dass das VCL zu stark an die Win-API gebunden ist und der ganze Code nicht portierbar ist.

Blöde Frage: Warum schafft es Lazarus, ein einheitliches Interface anzubieten? Programme sind fast ohne Änderungen auf allen Plattformen lauffähig. Stattdessen werden bei EMBA wieder 2 verschieden Frameworks entwickelt und gepflegt, die nichts miteinander gemein haben.

Schluss mit der Schönmalerei von Lazarus. Dann baut das endlich so, das der Code wirklich völlig ohne eine einzige Änderung sowohl von DElphi als auch von Lazarus ohne auch nur eine Einzige Inkompatibilität übersetzt wird. Ich musste nämlich bei derartigen Portierungsversuchen komplett andere ERfahrungen machen. Hab mich dazu auch schon im Thread "Einfache Freepascal IDE" und wohl auch bei "Erfahrungen mit Lazarus" zur Genüge geäußert. Hier hilft wohl am ehesten die Veröffentlichung der Kompletten Compilergrammatik, fertig für Compilergeneratoren als Eingabedatei, wie sich das für Open Source auch ziemen würde. Dann könnten andere mit einem per lex und yacc erstellten Parser einen Workaroud bauen.

[Daniel]

Die VCL einerseits und FireMonkey andererseits haben grundverschiedene Ansätze. Die VCL wurde für die Windows-API entwickelt und macht intensiven Gebrauch von ihr. Das geht bei den Handles los und hört bei der Nachrichtenverarbeiung noch lang nicht auf. FireMonkey hingegen wurde konstruiert, um möglichst wenig Infrastruktur voraus zu setzen und bei Bedarf auch ohne Handles und Messages auszukommen. Klar, dass die Interfaces da ein gutes Stück weit auseinander gehen. Wobei die RTL recht schön zeigt, wie man den gleichen Code über mehrere Plattformen erstrecken kann. Hier jetzt auf Krampf Brücken schaffen zu wollen, die da eigentlich nicht hingehören, würde alle Seiten ausbremsen und am Ende dennoch ein irgendwie unbefriedigendes Ergebnis darstellen.

[jaenicke]

Zitat von schöni:

Schluss mit der Schönmalerei von Lazarus. Dann baut das endlich so, das der Code wirklich völlig ohne eine einzige Änderung sowohl von DElphi als auch von Lazarus ohne auch nur eine Einzige Inkompatibilität übersetzt wird.

Ach, das wäre mir egal, mir würde es schon reichen, wenn Lazarus an sich ein ordentliches Konzept hätte (Komponenten einfach installieren und deinstallieren ohne das Gehampel mit dem Kompilieren von Lazarus selbst, ...), ordentlich funktionieren würde (ich sag nur Daemon Problem, ein Jahr schon war nen Fix da, aber nicht in der aktuellen Version drin... und ich such ewig wo das Problem ist... wie soll man auch drauf kommen, dass man irgendeine Unit manuell ins Projekt aufnehmen muss, weil diese beim Laden irgendwas Essentielles macht...) und ne ordentliche IDE hätte (zugegeben besser als Delphi 5 und früher, aber mehr auch nicht...).

Jedenfalls halte ich rein gar nix davon auf Teufel komm raus alles für alle Plattformen gleich zu machen. Der kleinste gemeinsame Nenner ist nicht immer die beste Lösung.
Zumal man ja beim Vergleich der Lazarus-Units sieht, dass diverse Funktionen schlicht nicht für alle Plattformen implementiert sind...

[Medium]

Insider, du missachtest einfach mal komplett die unterschiedlichen Zielsetzungen von Lazarus und VCL in der Entstehungsphase, die das grundlegende Design bis heute prägen. Wenn du so einfach portieren willst, nimm halt einfach Java, und fahre dein konstantes - meist ziemlich unbegründetes - Gebashejammer hier ein wenig runter. Emba kann nichts dafür, wenn du für deine Anforderungen das falsche Werkzeug wählst.

[JamesTKirk]

Zitat von schöni:

Zitat von Insider2004:

Wie fast jeder bereits bemerkt hat, ist das FMX-Interface nicht kompatibel zum VCL-Interface. D.h. VCL-Programme können nicht in FMX verwendet werden. Begründet wird dies von EMBA-Seite damit, dass das VCL zu stark an die Win-API gebunden ist und der ganze Code nicht portierbar ist.

Blöde Frage: Warum schafft es Lazarus, ein einheitliches Interface anzubieten? Programme sind fast ohne Änderungen auf allen Plattformen lauffähig. Stattdessen werden bei EMBA wieder 2 verschieden Frameworks entwickelt und gepflegt, die nichts miteinander gemein haben.

Schluss mit der Schönmalerei von Lazarus. Dann baut das endlich so, das der Code wirklich völlig ohne eine einzige Änderung sowohl von DElphi als auch von Lazarus ohne auch nur eine Einzige Inkompatibilität übersetzt wird. Ich musste nämlich bei derartigen Portierungsversuchen komplett andere ERfahrungen machen. Hab mich dazu auch schon im Thread "Einfache Freepascal IDE" und wohl auch bei "Erfahrungen mit Lazarus" zur Genüge geäußert. Hier hilft wohl am ehesten die Veröffentlichung der Kompletten Compilergrammatik, fertig für Compilergeneratoren als Eingabedatei, wie sich das für Open Source auch ziemen würde. Dann könnten andere mit einem per lex und yacc erstellten Parser einen Workaroud bauen.

Ein Compiler besteht nicht nur aus der Syntax, sondern auch aus der Semantik. Und die kannst du mit einer Grammatik nicht abbilden.

Ganz davon abgesehen sind Free Pascal und Delphi nicht eins zu eins kompatibel und werden es wohl auch nie sein (Stichwort: "moving target"). Zudem werden manche Details von Free Pascal anders implementiert als von Delphi (sogenannte Implementierungsdetails, auf welche Programmier eigentlich nicht aufbauen sollten, es manchmal aber doch tun...). So werden Interfaces in Delphi zu anderem Zeitpunkt freigegeben als in FPC. Oder "helper types" sind in FPC als eigener first class type implementiert, während sie in Delphi intern als Klassen, die von TClassHelperBase ableiten, implementiert sind.

Ich persönlich sage nicht, dass es vollkommen trivial ist Code unter Delphi und FPC parallel zu verwenden. Insider2004 wollte allerdings wohl darauf hinaus, dass man reinen FPC/Lazarus-Code relativ leicht auf unterschiedlichen Plattformen zum Laufen bringen kann.

Gruß,
Sven

[Lemmy]

Hi,

Zitat von JamesTKirk:

Ich persönlich sage nicht, dass es vollkommen trivial ist Code unter Delphi und FPC parallel zu verwenden. Insider2004 wollte allerdings wohl darauf hinaus, dass man reinen FPC/Lazarus-Code relativ leicht auf unterschiedlichen Plattformen zum Laufen bringen kann.

FPC/Lazarus sind aber genau zu dem Zweck geschaffen worden, Delphi und die VCL sind dagegen für die Windows API geschaffen worden. Jetzt zu meckern, dass die VCL nicht plattformunabhängig ist, finde ich unangebracht. Mit CLX und VCL.NET wurden schon Versuche unternommen die VCL auch für andere Plattformen bereit zu stellen und jedes mal ist man gescheitert. Eigentlich sollten wir (trotz des damit verbundenen Mehraufwands) froh sein, dass man bei Emba endlich aus alten Fehlern lernt...

Ob Firemonkey der richtige Weg ist, wird sich in einigen Jahren zeigen....