Als ergänzende Strategie für Konvertierungsversuche von delphi
gui formularen (gilt auch für wechsel auf neue Delphi
version, die evtl eure erforderlichen komponenten nicht installierbar haben):
Man kann einfachen Kram ja direkt in lazarus öffnen und konvertieren, aber das ist eben wirklich selten 100% erfolgreich
für reale Projekte mit jahrelanger Geschichte.
Meistens sind die
pas/
dfm ja so aufgebaut, das delphi die komponenten dann zur Entwicklungszeit bereits laden kann
und auch nett auf dem bildschirm darstellt, wenn dafür vorgesehen. Wenn man nun die gleiche Kombination in Lazarus
direkt lädt, kommt von der lazarus
IDE dann genau wie bei einem Delphi, das die ganzen Komponenten auch nicht hat,
bei jeder Komponente eine Fehlermeldung. Das kann einen schnell verzweifeln lassen.
Daher mit solchen Formularen mal einfach versuchen, den Inhalt der
dfm zu konvertieren, bei delphi gab es dafür
immer gexperts components2code. Ergebnis ist dann: alles das was du vorher markiert hattest, wird als instanzvariable
mit create instanziiert und anschliessend weden alle properties zur laufzeit gesetzt, die normalerweise aus der
dfm
kommen. danach packst du den code in dein form oncreate event und löscht die gesamten markierte komponenten. das geht
oft überraschend gut.
Wenn man sein formular schon mal so umgebaut hat, kann es in delphi bei bedarf noch weiterhin benutzt werden, meckert dann
aber nur beim compilieren, wenn irgendwelche Klassen gewisse eigenschaften nicht haben oder die ganze Klasse unbekannt
ist.
Alle komponenten müssen dann gar nicht mehr installiert sein. Ist zwar dann nicht mehr so komfortabel, das im Formular
durch anklicken mit dem Objektinspektor zu bearbeiten, aber ganz oft sieht man auch erst dann in dem dadurch entstandenen
Code, was da alles mit wem zusammenhängt. Und auch das sind oft ruselige Altlasten, die man gar nicht so mehr auf
dem plan hatte.
Das damit neu erzeugte formular, was eigentlich keins mehr ist, kann dann oft realtiv leicht mit compiler direktiven
angepasst werden, wenn es bei der Zielplattform (egal ob neue delphi Version oder lazarus) die komponente gar nicht
in der
IDE gibt oder andere Properties und events hat.
Und eigentlich komplexe
GUI Komponenten, die du nur in alten Versionen in deinem Delphi verfügbar hast, kannst du dann
in einer simplen
unit ggf selber von was ähnlichem ableiten und dir bei jeder Property noch mal überlegen, ob du das
überhaupt weiterhin so haben willst.
wie jaenicke schon schrieb, der große Vorteil wäre wenn es eh nicht mehr alles vermischt in form/
pas/
dfm befindet, aber
die realität von vielen Projekten ist nun mal anders. Den o.a. erzeugten Code, der das formular ohne
dfm erstellt, kannst du
dann aber schon mal als basis in eine andere
Unit packen.
Und das ist dann wesentlich einfacher lauffähig zu machen, als wenn du erst mal versuchst, sämtliche von dir benutzten
Komponeten in passender version in die Ziel
IDE zu bringen, insbesondere wenn es den Komponentenhersteller gar nicht
mehr gibt oder der die Sachen in neuen Versionen so umgebaut hat, das die eh nicht mehr kompatibel wäre.
Viele Komponenten haben einen riesen overhead für visuelle Delphi
IDE Integration, würden aber zur Laufzeit erzeugt
auch so benutzbar direkt aus der
Unit sein, auch wenn es in der
IDE gar nicht mehr installierbar ist.
Ein projekt so in der Art umzubauen ist zwar immer noch keine 5 minuten klick job, aber deutlich effektiver, als
zu versuchen, alte fremdkomponenten in neuer
IDE version installierbar zu machen, egal ob delphi oder lazarus.
In Lazarus gibt es dafür auch mitgelieferte units, auf deren basis man das ähnlich wie in gexperts selber
bauen könnte
./components/lazutils/compwriterpas.pas
This writes the .dfm as a routine that can be called to create the form with the .dfm properties.
See examples/pascalstream/