DFM-Datei in anderem Programm als Vorschau anzeigen

[Harry Stahl]

Ich bin gerade dabei, meinem Dateimanager-Programm eine Vorschau-Ansicht für Delphi-Formulare zu spendieren (.DFM-Dateien). Man muss also nur auf eine DFM-Datei klicken und schon bekommt man die Form im Vorschaufenster angezeigt. Die .PAS-Datei wird nicht benötigt und auch kein Delphi auf dem Computer. Das ist eine Sache, die ich mir selber schon lange gewünscht habe, bei den vielen Formularen ist das z.B. im Rahmnen einer Suche ganz praktisch, die mal kurz optisch anzusehen, ohne die in eine Entwicklungsumgebung laden zu müssen.

Das funktioniert soweit schon ganz gut, es werden Forms und Frames angezeigt (siehe anliegenden Screenshot).

Drei Probleme bleiben, wo ich derzeit nicht so richtig weiterkomme, evtl. weiß jemand Rat:

1. Von den Frames kann ich derzeit nur die Basis-Frames anzeigen. Falls das Frame eine Ableitung von einem anderen Frame ist, kommt der Hinweis, dass das Vorfahr-Frame nicht gefunden wurde und der Vorgang wird abgerochen.

Um das Frame ( / Formular) einzulesen, verwende ich die TReader-Klasse:

Delphi-Quellcode:

 ...
 Reader := TReader.Create(S2, 4096); // S2 enthält den schon eingelesenen DFM-Stream
 FormDyna := Tform.Create(NIL);

 if TypeFrame then begin
    AFrame := TFrame.Create(FormDyna);
    Reader.ReadRootComponent(AFrame); // Hier knallt es, wenn ein Vorfahr-Frame vorhanden ist
    AFrame.Parent := FormDyna;
    AFrame.visible := True;
  end else begin
    Reader.ReadRootComponent(FormDyna);
  end;
  ...

Was könnte man hier machen, um das Vorfahr-Frame dem Reader zur Verfügung zu stellen?

2. Wenn der Reader eine unbekannte Klasse findet, dann steigt er aus und liefert kein verwendbares Ergebnis zurück. Das ist also etwas anders, als wenn Delphi eine Form-Datei lädt und fehlende bzw. unbekannte Komponenten beanstandet. Es fehlen dann evtl. einige Komponenten, aber das Form wird jedenfalls geladen. Gibt es irgendeine Option oder sonstige Möglichkeit, dem Reader zu sagen, dass er das Laden fortsetzen soll?

Bislang habe ich das so gelöst, dass ich die unbekannten Komponenten nach dem Einlesen an Ort und Stelle und in der ursprünglichen Position gegen ein TPanel austausche, mit dem Namen der Klasse versehen. Das würde ich auch weiterhin so machen, allerdings sind auch bekannte Standard-Komponenten von Delphi-Version zu Delphi-Version schon mal anders, so dass auch da immer noch eine Abbruchgefahr bleibt, insofern wäre es schön, wenn der Reader trotzdem weiterliest.

3. Das Programm kann natürlich nur die Komponenten anzeigen, die es kennt, sprich, die man mit RegisterClass registriert hat. Das kann ich natürlich für alle Standard-Delphi-Klassen machen und für das was ich hier sonst noch so an Drittkomponenten erworben habe.

Aber andere Anwender werden halt andere Komponenten und Klassen haben, die sie vielleicht auch ganz gerne in der Vorschau sehen würden (statt des Ersatzpanels). Kann man die Klassen der Drittkomponenten z.B. über eine DLL-Datei (die der Anwender selber erstellen und in das Programmverzeichnis kopieren müsste) meinem Programm bekannt machen oder ist eine andere Lösung denkbar?

[Sir Rufo]

Eine funktioniert-immer Lösung wirst du da nicht hinbekommen, denn z.B. die Vorfahr-Klasse kann sich irgendwo oder sogar nirgendwo befinden.

Wie willst du dann wissen, wie das aussehen soll?

Dann gibt es noch das Problem mit den Default-Werten, die werden nicht in der DFM abgelegt.

Kurz gesagt, auch die IDE kann nur dann mit der DFM etwas anfangen, wenn alle Informationen (Bibliotheken, Packages) vorhanden und korrekt eingebunden sind. Und du möchtest das jetzt ohne diese Informationen hinbekommen?

Sportlich, aber sei nicht traurig, wenn du da kein vernünftiges Ergebnis bekommst

[Harry Stahl]

Zitat von Sir Rufo:

Kurz gesagt, auch die IDE kann nur dann mit der DFM etwas anfangen, wenn alle Informationen (Bibliotheken, Packages) vorhanden und korrekt eingebunden sind. Und du möchtest das jetzt ohne diese Informationen hinbekommen?

Nein, genau darum geht es, wie ich daran komme. Letztlich brauche ich ja "nur" die Klassen.

Die werden also mit

Delphi-Quellcode:

  RegisterClass(TPanel);
  RegisterClass(TMemo); 
  RegisterClass(TTimer);

... usw. registriert. Soweit ich die hier bereits in meinem Programm habe, kein Problem. Wenn Komponenten fehlen, sieht das z.B. aus, wie im ersten anliegenden Screenshot. Habe ich die TMS-Komponenten aber registriert, sieht es aus, wie im 2. Screenshot.

Eine meiner Fragen war nun, ob man über eine DLL, die weitere Klassen registriert, diese Klassen meinem Programm zugänglich machen kann. Der Anwender (=geneigte Entwickler) müsste in diesem Falle also z.B. nur in seiner DLL die ganzen RegisterClass-Aufrufe für "seine" Komponenten vornehmen.

[Sir Rufo]

Das war mir schon klar ... ich wollte dir nur die nächste Hürde zeigen.

Und nein, du kannst keine Klasse aus einer DLL importieren. Dazu würdest du eine BPL benötigen, die dann aber wieder exakt zu deiner Delphi-Version und den Bibliotheken passen muss.

[sh17]

Ich hab das so gelöst, das ich mir automatisch zu allen DFM-Dateien ein riesen-großes Projekt erzeugen lasse (ohne die Logik, nur das Benötigte zur Darstellung der DFM), das dann in eine Monster-EXE kompiliere und dann schön darin über eine Listbox mir alle Formulare anschauen kann. Das sollte auch mit den Frames klappen, hab ich aber noch nicht getestet, weil ich solche Vererbungen nicht nutze.

[uligerhardt]

Zitat von Harry Stahl:

Aber andere Anwender werden halt andere Komponenten und Klassen haben, die sie vielleicht auch ganz gerne in der Vorschau sehen würden (statt des Ersatzpanels). Kann man die Klassen der Drittkomponenten z.B. über eine DLL-Datei (die der Anwender selber erstellen und in das Programmverzeichnis kopieren müsste) meinem Programm bekannt machen oder ist eine andere Lösung denkbar?

Vielleicht nur ein Hirngespinst, aber...: Kannst du nicht aus der Registry die "Known Packages" oder was ähnliches lesen und dir die Info aus den dort gelistetn BPLs holen? Dabei müsstest du natürlich wissen, welche Delphi-Version die richtige für die DFM ist, aber das Problem hast du ja sowieso.

[Sir Rufo]

Zitat von uligerhardt:

Zitat von Harry Stahl:

Aber andere Anwender werden halt andere Komponenten und Klassen haben, die sie vielleicht auch ganz gerne in der Vorschau sehen würden (statt des Ersatzpanels). Kann man die Klassen der Drittkomponenten z.B. über eine DLL-Datei (die der Anwender selber erstellen und in das Programmverzeichnis kopieren müsste) meinem Programm bekannt machen oder ist eine andere Lösung denkbar?

Vielleicht nur ein Hirngespinst, aber...: Kannst du nicht aus der Registry die "Known Packages" oder was ähnliches lesen und dir die Info aus den dort gelistetn BPLs holen? Dabei müsstest du natürlich wissen, welche Delphi-Version die richtige für die DFM ist, aber das Problem hast du ja sowieso.

Das würde ansatzweise gehen, aber nicht bei

Zitat von Harry Stahl:

Die .PAS-Datei wird nicht benötigt und auch kein Delphi auf dem Computer

So eine DFM kann man nur dann sinnvoll interpretieren, wenn der gesamte Kontext vorhanden ist. Und dieser Kontext kann dann auch noch von vielen Faktoren abhängig sein.

[Uwe Raabe]

Zitat von Harry Stahl:

Die .PAS-Datei wird nicht benötigt und auch kein Delphi auf dem Computer.

Vielleicht eine philosophische Frage, aber was soll dann überhaupt die DFM-Datei auf dem Computer?

[sh17]

Zitat von Uwe Raabe:

Zitat von Harry Stahl:

Die .PAS-Datei wird nicht benötigt und auch kein Delphi auf dem Computer.

Vielleicht eine philosophische Frage, aber was soll dann überhaupt die DFM-Datei auf dem Computer?

Ich könnte dann die DFM meinem Designer geben, der dann seine schlauen Kommentare hinterlässt

[Uwe Raabe]

Zitat von sh17:

Ich könnte dann die DFM meinem Designer geben, der dann seine schlauen Kommentare hinterlässt

Screenshot? Da gibt es Viewer en masse und sogar Programme (z.B. SnagIt), mit denen man direkt darauf rummalen kann. Zusätzlich kann man die Screenshots auch noch für die Anwender-Dokumentation verwenden.