Tool für "Form to Code" verfügbar?

[Harry Stahl]

Die meisten von Euch kennen sicher die GExperts, mit denen man Komponenten auswählen kann und dann den Befehl "Components to Code" aufrufen kann und man erhält dann die Variablen und den Code welcher die Komponenten zur Laufzeit erzeugt und mit den Vorgaben belegt.

Gibt es eigentlich ein Tool (erst mal für die VCL), welches auch eine ganze Form so "umwandelt", das alles zur Laufzeit erzeugt wird? Also auch Einstellungen der Form, die Zuordnungen der Eventhandler (Form-Prozeduren) zu den "OnEvents" vornimmt, etc.

Ich frage das deshalb, weil ich überlege, bestimmte (einfache) Forms, die ich immer wieder in vielen Projekten benötige, dynamisch zur Laufzeit erstellen zu lassen. Das hätte den Vorteil, dass ich diese dann in allen Delphi-Versionen verwenden könnte und nicht jedes mal, wenn es eine neue Delphi-Version gibt, einen neuen Ordner erstellen muss, wo diese globalen Forms für das neue Delphi reinkommen (denn ältere Delphis können oft die Fassungen der vom neuen Delphi übernommenen Form nicht lesen, weil es z.B. neue Eigenschaften gibt.) Das hätte auch noch einen weiteren Vorteil, wenn ich kleine Erweiterungen oder Fehlerkorrekturen bei diesen globalen Forms mache, dann könnten davon auch direkt noch Projekte profitieren, die ich derzeit noch mit älteren Delphis erstelle. Müsste also nur an einer Stelle was ändern (evtl. könnte man diese Forms mit ein paar IFDEF'S auch direkt so anpassen, dass man sie auch für FMX verwenden kann).

Allerdings würde ich mir mit so einer Umstellung nicht so viel Arbeit machen wollen, daher wäre es toll, wenn es so ein Tool schon gäbe...

[Harry Stahl]

Frag noch mal nach, ob da sich evtl. in der Zwischenzeit was getan hat...

[jaenicke]

Nach so etwas hatte ich auch schon einmal geschaut, wenn auch aus anderer Motivation. Aber so komplett scheint es das nicht zu geben.

Bezüglich der verschiedenen Versionen:
Damit hatte ich bisher keine Probleme, denn neuere Versionen von Delphi können ältere DFMs ja lesen und ergänzen dann nur ggf. Eigenschaften. Die übernehme ich dann aber schlicht nicht ins Repository, wenn ein Quelltext für mehrere Versionen funktionieren soll.

Denn ich halte es für selbstverständlich, dass man beim Einchecken jede einzelne Änderung prüft, ob nun im Quelltext oder in der Formulardefinition. Was ich nicht absichtlich geändert habe, fliegt dabei raus.

[Harry Stahl]

Zitat:

Zitat von jaenicke (Beitrag 1407282)

Bezüglich der verschiedenen Versionen:
Damit hatte ich bisher keine Probleme, denn neuere Versionen von Delphi können ältere DFMs ja lesen und ergänzen dann nur ggf. Eigenschaften. Die übernehme ich dann aber schlicht nicht ins Repository, wenn ein Quelltext für mehrere Versionen funktionieren soll.

Ich möchte damit letztlich per Code eine "globale" Form erzeugen, die dann unter allen Delphi-Versionen läuft. Zwar übernehmen neuere Delphi-Formulare die alten, aber für ältere Delphi-Versionen gibt es bestimmte Komponenten noch nicht, da muss ich die Lösung dann anders gestalten. Ich möchte aber nicht unterschiedliche Formulare für unterschiedliche Delphi-Versionen erzeugen / verwalten, sondern eben zur Laufzeit soll entsprechend der vorliegenden Delphi-Version die Erzeugung gesteuert werdne.

Gedacht ist hier mal an eine kommerziell vertriebene Lösung, wo Entwickler mit unterschiedlichen Delphi-Versionen diese Form nutzen können.

Ich will letztlich nur eine Unit erzeugen, die selber zur Laufzeit das Formular erstellt.

[KodeZwerg]

Ist das was Du vor hast nicht Sinn und Zweck einer .dll Datei? Helfer die man immer mal braucht oder gar ganze Formulare, geht beides.

[Harry Stahl]

Nein, DLL hilft nicht.

Weder befreit es mich davon, verschiedene Formulare / DLL's zu erzeugen, auch ist es keine Lösung, da es um eine Form geht, die zunächst unter FMX zur Laufzeit erstellt werden soll. Die soll von den Entwicklern einfach in das jeweilige Projekt eingebunden werden und dann sowohl unter Windows / MAC / und Linux (mit FMXLinux) zur Verfügung stehen (aber in einem 2. Schritt auch für VCL-Programme).

Es ist ein Ersatz für die .chm- HIlfe, die ja nur unter VCL/Windows zur Verfügung steht. Ich habe eine Lösung entwickelt, wo ein Management-Programm eine Hilfe-Datei erzeugt und diese Hilfe in diesem "globalen" Formular angezeigt werden soll.

Da möchte ich aber nicht nur das aktuelle Delphi 10.2 unterstützen, sondern auch ältere Delphi-Versionen und auch VCL (Windows geht mir da gehörig auf den Nerv mit .chm-Dateien, die nicht angezeigt werden können, weil sie auf einem Netzwerklaufwerk liegen).

Anliegend mal ein Screenshot (unter Linux) zur Verdeutlichung, worum es geht. Die Form ist jetzt nicht so Komplex, aber ein paar Stunden würde ich sicher schon dran sitzen, wenn ich die Erzeugung der Komponenten manuell programmieren müsste...

[Frickler]

Vor dem Problem habe ich auch schon gestanden. Ich habe mir dann was selbst gestrickt auf Basis von "CreateMessageDialog()" aus Dialogs.pas, da wird ja ein Formular komplett aus Code generiert. Zusätzliche Komponenten generiert mir "components to code" von den GExperts. Das ist leider ein mordsmäßiges Gebastel, bis das schön aussieht....

Es gibt auch ein Programm, welches ganze Formulare in Code verwandelt. Aber das ist ewig veraltet:
http://www.felix-colibri.com/papers/...fm_parser.html
http://www.felix-colibri.com/papers/...t_to_code.html

[hoika]

Hallo,
also mit Help&Manual erzeugen wir aus einer Quelle CHM- und PDF-Dateien.
Die PDF kann man schön mit QuickPDF anzeigen.

[TiGü]

Zitat:

Zitat von hoika (Beitrag 1407398)

Hallo,
also mit Help&Manual erzeugen wir aus einer Quelle CHM- und PDF-Dateien.
Die PDF kann man schön mit QuickPDF anzeigen.

Falscher Thread?

[MichaelT]

Dergleichen habe ich noch nichts gefunden.

Ich erzeuge Forms beinahe nur programmatisch bis auf die von dir angesprochenen komplexen welche zumeist sehr einmalig sind und sowieso in einer anderen Technologie anderes aufgebaut. Unsere Motivation war ein wenig anders gelagert.

Leicht ist das Unterfangen nicht.

Du weißt bei manchen Properties den Initialiserungsstatus bspw. nicht, da der erst im Konstruktor gesetzt wird. Deswegen musst du alle Property Values rausschreiben.

Damit könntest du zwar jene Properties die du nicht setzen kannst überlesen und die noch nicht verfügbaren auf Default lassen. Das entspricht in etwa dem manuellen Implementieren. Die read only muss man noch ignorieren und dann musst du deine Komponenten so aufgebaut, der innere Status mit dem abgespeicherten Property Wert gegebenenfalls zusammenstimmt.

Ich hatte mir ganz schlicht einen Knopf gebaut der nicht visible ist an sich und der einfach den Status aller erzeugten Komponenten rausschreibt auf dem Weg habe ich mir zumindest mal eine Quick Shot vom Gröbsten gemacht. Besser als zur Laufzeit wirst du sowieso nicht. Das war der Code für den Constructor oder die erste Implementierung.

Der nächste Affenzirkus folgt sofort, dass du Marken im Constructor bräuchtest die nicht überschrieben werden dürfen usw. im Falle einer Änderung. Soweit habe ich mir die Sache nicht angetan.

[Edit] Das war ganze passierte vor der Zeit vor Rtti. Wobei ich nicht weiß ob du private members mit Hilfe von Rtti kannst setzen. Mir hat damals Ableiten nicht geholfen. Damit hätte wir müssen ein WidgetSet und soetwas interessiert mich nicht. Ein Komponente in Ehren hie und da ...

Selbst datengetrieben hat uns unter Winforms (.net 2.0) bewogen von der Rectangle weg jedes Control zu bauen. Das macht nur Sinn, wenn du die Fähigkeiten der Anwendung so aufbläst, dass sie mit Contexten, Views im Hintergrund usw... kann arbeiten. Aber du verlierst die gesamte Toolingfähigkeit. Alles hinter einer pragmatischen Lösung wächst sich schnell aus. Nichts gegen das Framework welches meine Cos damals bauten, das muss dann schon Server Umzug (auf eine andere Datenbank den Zugriff generieren usw...). Da hat bei Planungs- und Optimierungssystemen und durch den Einsatz in 5 gleichartigen Projekten Sinn gemacht. Halbe Lösungen bei Wiederverwendung verzögern das Auftreten von Problemen nur.

Zitat:

Zitat von Harry Stahl (Beitrag 1388452)

.