DFM-Datei in anderem Programm als Vorschau anzeigen

[sh17]

Zitat von 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.

Sorry, ich hätte kein Bock, nach jeder Änderung einen Screenshot zu machen und zurück zum Designer zu schicken. So drück ich aus Knöpfchen und hinten fällt eine fertige EXE mit allen Formularen inkl integrierten Kommentarsystem heraus. Da kann der Designer direkt in der Anwendung seinen Senf zur DFM dazu geben, das wird in einer DB gespeichert und kann von mir gegen-Kommentiert werden.

Wenn ich Zeit habe, ich wollte das Ding eh OpenSource stellen.

[Uwe Raabe]

Zitat von sh17:

So drück ich aus Knöpfchen und hinten fällt eine fertige EXE mit allen Formularen inkl integrierten Kommentarsystem heraus. Da kann der Designer direkt in der Anwendung seinen Senf zur DFM dazu geben, das wird in einer DB gespeichert und kann von mir gegen-Kommentiert werden.

Verstehe, dann braucht man natürlich auch kein Delphi, aber auch keinen DFM-Viewer, da die ja schon in der EXE drin sind und nicht als einzelne Dateien auf der Platte rumliegen.

[Harry Stahl]

Zitat von 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.

OK, das ist natürlich auch ein interessanter Weg, um das gewünschte Ziel zu erreichen. Jedenfalls zeigt mir Dein Hinweis, dass offensichtlich nicht nur ich an so einer Funktion ein Interesse hat.

[Harry Stahl]

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?

Der Hinweis war eigentlich nur als technischer Hinweis gedacht, so dass sich niemand, der sich mit meiner Frage beschäftigt, unnötig Gedanken über das erforderliche Umfeld macht.

Die Funktionalität kann für mehrere Situationen von Bedeutung sein:

- Ich will alle meine Dialoge DPI-Aware machen. Mit dieser Funktion kann ich schnell mal mir die Dialoge ansehen, ich weiß inzwischen ja, für welche Komponenten Handlungsbedarf bestehen und verschaffe mir da schnell mal eine Übersicht.

- Ich arbeite an einer Dokumentation für die Entwicklung oder ein Handbuch und will mir als Grundlage der Beschreibung mal kurz den Dialog ansehen.

Könnte man doch auch direkt über das Programm machen, wird vielleicht einer Fragen?

Ja, aber manche Dialoge werden eben erst angezeigt, wenn bestimmte Programm- oder Datenkonstellationen vorliegen. Die immer erst herbeizuführen, kann ziemlich zeitaufwändig sein. Diese Zeit will ich mir ersparen.

Diese Dokumentations-Arbeit kann u.U. auch unterwegs mal auf einem Notebook gemacht werden, wo eben kein Delphi drauf ist, daher sollte dies nicht eine Voraussetzung für die Funktionalität sein.

[Harry Stahl]

Zitat von 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.

Ja, das hatte ich befürchtet (schade eigentlich).

Ich frage mich gerade, ob es denn ein Weg sein könnte, dass ich das Objekt dann in der DLL, welches die Klasse registriert hat, erzeuge und selber an die Stelle im Formular einhänge, wo es hinsoll. Ich könnte ja das ParentControl mit an die DLL übergeben geben (im übertragenen Sinne also "NewClassControlFromDLL.Parent := TControl (ParentControl)).

Oder gibt es da einen grundsätzlichen Denkfehler?

[Harry Stahl]

Das mit den Frames konnte ich bislang nur so lösen, dass ich die Vorfahrelemente aus dem Nachfolger-Formular durch ein TPanel ersetze, dann wird das Formular ohne Fehler geladen, es fehlen aber die Vorfahren.

Kann man eigentlich eine Klasse auch irgendwie registrieren, indem man die Vorfahren im laufenden Programm "einliest", also aus den .pas und dfm-Dateien? Wenn ja, wie müsste man da vorgehen?

Mal abgesehen, dass immer noch das eine oder andere zu klären ist, funktioniert die Sache schon ganz gut, der anliegende Screenshot zeigt ein DFM-Formular im "Design-Time" Modus, mit direkten Zugriff auf die Events der angezeigten Komponenten.

Habe auch schon mal ein kleines Vorab-Video gepostet (dass ich aber noch mal neu machen werde, wenn die Endfassung draußen ist), man kann sich aber schon halbwegs ein Bild machen, worauf ich hinaus will.

https://youtu.be/QOUAFQaApHY

[EWeiss]

Zitat:

Mal abgesehen, dass immer noch das eine oder andere zu klären ist, funktioniert die Sache schon ganz gut, der anliegende Screenshot zeigt ein DFM-Formular im "Design-Time" Modus, mit direkten Zugriff auf die Events der angezeigten Komponenten.

Harry!
Habe keinen Hilfsreichen Beitrag für dich aber..

gruss

[Harry Stahl]

Zitat von EWeiss:

Zitat:

Mal abgesehen, dass immer noch das eine oder andere zu klären ist, funktioniert die Sache schon ganz gut, der anliegende Screenshot zeigt ein DFM-Formular im "Design-Time" Modus, mit direkten Zugriff auf die Events der angezeigten Komponenten.

Harry!
Habe keinen Hilfsreichen Beitrag für dich aber..

gruss

Danke!

Ich habe mir überlegt, um die unbekannten Klassen der User-Komponenten einbinden zu können, ein Plugin-System zu entwickeln.

Dabei müsste eine PlugIn-DLL lediglich die Klassen registrieren, die sie zur Verfügung stellt und eine Export-Funktion "GetWinControlFromClass", die so aussieht:

Delphi-Quellcode:

procedure ReadComponent (MyComponent: TComponent; InStream: TMemoryStream);
var
  outstream: TMemoryStream;
begin
  Instream.Position := 0;
  OutStream := TMemoryStream.Create;
  try
    ObjectTextToBinary(InStream, outstream);
    OutStream.Position := 0;
    OutStream.ReadComponent(MyComponent);
  finally
    OutStream.Free;
  end;
end;

function GetWinControlFromClass (ClassName: ShortString; InStream: TMemoryStream; AnOwner: TControl): TControl; stdcall;
var
  CRef : TPersistentClass;
begin
  CRef := GetClass(String (ClassName));
  if CRef<>nil then
  begin
    Result := TControl(TControlClass(CRef).Create(AnOwner));
    ReadComponent (Result, Instream);
  end;
end;

exports
  GetWinControlFromClass;

begin
  RegisterClass (TSpeedButton); {slClasses.Add('TSpeedButton');}
end.

Mein Dateimanager-Programm übergibt der Funktion den Klassennamen des zu erzeugenden Controls und den Textstream der Komponente aus der DFM-Datei.

Die Funktion liefert dann das Control zurück und ich kann die fehlende Klasse in Form des erhaltenen Controls in das Formular einbauen, verkürzt hier mal so dargestellt:

Delphi-Quellcode:

if DLLhandle <> 0 then begin
    co := DFMPlugIn.GetWinControlFromClass ('TSpeedButton', ms, self);
    if co <> NIL then begin
      showmessage (co.Name); //OK, geht, Name stimmt auch

      co.Parent := self; // Fehler:--> TFont kann nicht zu TFont zugewiesen werden
      co.Left := 100;
      co.Top := 100;

      co.Visible := True;
    end;
  end;

Leider liefert die Zuweisung zum Parent immer den Fehler "TFont kann nicht zu TFont zugewiesen werden".

Jemand eine Idee, warum das hier nicht geht, bzw. was man ändern muss, so dass es geht?

[Sir Rufo]

Weil TFont in der DLL ein anderer Typ ist als TFont in der Anwendung.

Du erinnerst dich an das Thema mit den Klassen und DLL?

[Harry Stahl]

Zitat von Sir Rufo:

Weil TFont in der DLL ein anderer Typ ist als TFont in der Anwendung.

Du erinnerst dich an das Thema mit den Klassen und DLL?

Ja, Klassen kann man nicht exportieren, aber die erzeugten Klassen-Objekte. Und nichts anderes mache ich in der DLL. Hier sind sogar DLL und Programm von der gleichen Compiler-Version erzeugt, da müsste doch das TFont aus der DLL mit dem TFont aus dem Programm identisch sein, oder?