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:

Zitat von Sir Rufo (Beitrag 1308951)

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:

Zitat von Harry Stahl (Beitrag 1308944)

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:

Zitat von uligerhardt (Beitrag 1308990)

Zitat:

Zitat von Harry Stahl (Beitrag 1308944)

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:

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:

Zitat von Harry Stahl (Beitrag 1308944)

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:

Zitat von Uwe Raabe (Beitrag 1308997)

Zitat:

Zitat von Harry Stahl (Beitrag 1308944)

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:

Zitat von sh17 (Beitrag 1309002)

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.

[sh17]

Zitat:

Zitat von Uwe Raabe (Beitrag 1309023)

Zitat:

Zitat von sh17 (Beitrag 1309002)

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:

Zitat von sh17 (Beitrag 1309026)

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:

Zitat von sh17 (Beitrag 1308969)

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:

Zitat von Uwe Raabe (Beitrag 1308997)

Zitat:

Zitat von Harry Stahl (Beitrag 1308944)

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:

Zitat von Sir Rufo (Beitrag 1308964)

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.. :thumb::thumb:

gruss

[Harry Stahl]

Zitat:

Zitat von EWeiss (Beitrag 1309452)

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.. :thumb::thumb:

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

Delphi-Quellcode:

TFont

in der DLL ein anderer Typ ist als

Delphi-Quellcode:

TFont

in der Anwendung.

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

[Harry Stahl]

Zitat:

Zitat von Sir Rufo (Beitrag 1309577)

Weil

Delphi-Quellcode:

TFont

in der DLL ein anderer Typ ist als

Delphi-Quellcode:

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?

[Sir Rufo]

Es ist nun mal so wie es ist.

Und bei der Zuweisung des Fonts passiert ein

Delphi-Quellcode:

TFont.Assign

. Und dort wird überprüft, ob die Instanz vom Typ

Delphi-Quellcode:

TFont

ist. Ist sie aber nicht (sieht man, wenn man sich den Referenzzeiger von

Delphi-Quellcode:

TObject.ClassType

anschaut.

Sehen gleich aus, heissen gleich, haben aber eine andere Referenz => ungleich und kein Assign möglich.

[Harry Stahl]

So ein Mist...:(

Aber danke für die Erklärung.

[Sir Rufo]

Eine Möglichkeit wäre noch, dass du dem Control in der DLL ein Panel zur Verfügung stellst und dann der DLL das Handle von dem Panel übergibst, dann kann das Control dort hingezeichnet werden.

[Harry Stahl]

Vielen Dank für den Tipp. Werde ich morgen Abend auf jeden Fall mal ausprobieren, dass könnte zumindest eine Notlösung sein, wenn die anderen Ansätze, die ich mir überlegt habe, auch nicht funktionieren sollten...

[Harry Stahl]

Erfreulicherweise habe ich doch noch eine Möglichkeit gefunden, das Objekt in mein Formular zu übernehmen, mit CreateParented geht es:

Delphi-Quellcode:

function GetWinControlFromClass (ClassName: ShortString; InStream: TMemoryStream; AnOwner: TControl): TControl; stdcall;
var
  CRef: TPersistentClass;
  AControl: TControl;
  pn: TPanel;
begin
  Result := NIL;

  pn := Tpanel.CreateParented(TWinControl(AnOwner).handle); // That Rocks !!

  CRef := GetClass(String (ClassName));
  if CRef<>nil then
  begin
    AControl := TControl(TControlClass(CRef).Create(AnOwner));
    try

      AControl.Parent := pn;
      ReadComponent (AControl, Instream);
      //AControl.Parent := pn;

      pn.BevelOuter := bvNone;

      pn.Left := TWinControl (AControl).Left;
      pn.Top := TWinControl (AControl).Top;

      AControl.Left := 0;
      AControl.Top := 0;

      if ObjectHasProp (AControl, 'Width', tkInteger) then begin
        pn.AutoSize := True;
      end else begin
        pn.Width := 32;
        pn.Height := 32;
      end;

      pn.Visible := True;

      AControl.Visible := True;
      Result := TControl (pn);
    except
    end;
  end;
end;

Auf der Aufrufseite darf und braucht keine Parentzuweisung mehr erfolgen, daher kommt es auch nicht mehr zum Asign (TFont) usw. und alles funktioniert wie gewünscht (kleine Einschränkung, für das Objekt funktioniert kein Align). Kann das zurückgegebene Panel dann in die Form oder z.B. in ein anderes Panel einfügen.

Einzige Sache, die mich gerade etwas irritiert: Es funktioniert mit TEdit, TButton, TListBox, usw., aber nicht mit TSpeedButton.

Das TSpeedbutton-Objekt wird ordnungsgemäß erzeugt, aber nicht angezeigt. Warum nur (TSpeedButton ist natürlich als Klasse in der DLL registiert)?

[Harry Stahl]

Es ist doch schön, wenn man sich die Antworten selber geben kann:

Man benötigt statt des TPanels ein TForm, dann funktioniert alles wie gewünscht.

[Sir Rufo]

Das mit den Klassen-Referenzen, die du da so austauschst ist schon hart an der Schmerzgrenze. Ich würde nur das Handle übergeben und zurück eher ein Interface.

Du kannst dir auch mal anschauen, wie man den PreviewHandler in Delphi einbindet. Denn da passiert eigentlich genau das gleiche.

Ich habe die Daten und den Platz zum Anzeigen und im System ist der PreviewHandler registriert der diese Daten auf dem zugewiesenen Platz darstellt.

[Harry Stahl]

Zitat:

Zitat von Sir Rufo (Beitrag 1309683)

Das mit den Klassen-Referenzen, die du da so austauschst ist schon hart an der Schmerzgrenze. Ich würde nur das Handle übergeben und zurück eher ein Interface.

Kleine Bitte um Hilfestellung, da ich relativ unerfahren mit Interfaces bin: Wie würde man das machen? Interfaces dürften ja hier den Vorteil haben, dass ich hinterher nicht selber aufräumen muss?

Zitat:

Zitat von Sir Rufo (Beitrag 1309683)

Du kannst dir auch mal anschauen, wie man den PreviewHandler in Delphi einbindet. Denn da passiert eigentlich genau das gleiche.

Wo finde ich den PreviewHandler?

Zitat:

Zitat von Sir Rufo (Beitrag 1309683)

Ich habe die Daten und den Platz zum Anzeigen und im System ist der PreviewHandler registriert der diese Daten auf dem zugewiesenen Platz darstellt.

Das verstehe ich wahrscheinlich erst, wenn ich mir den PreviewHandler angesehen habe. Wobei ich mal vermute, dass ich dafür ein installiertes Delphi auf dem PC haben muss?

Wenn es also besser geht, gerne. Grundsätzlich bin ich schon mal froh, eine Variante zu haben, die (nach erstem Anschein) ganz gut funktioniert. Auch TMS-Komponenten konnte ich so auf diese Weise einbinden, sollte dann auch so mit allen anderen funktionieren.

[Sir Rufo]

Der PreviewHandler hat nichts mit Delphi zu tun, sondern sorgt dafür, dass du im Explorer eine Vorschau sehen kannst (z.B. von einer PDF-Datei).

Diese müssen sich entsprechend registrieren und man könnte auch aus deinem Formular-Anzeiger einen PreviewHandler machen, der dann ganz einfach mit dem Windows Explorer funktioniert.

Hier die Definition des Interfaces
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Um diesen Preview (nach der Initialisierung) dann anzuzeigen, reicht es die Methode

Delphi-Quellcode:

SetWindow

aufzurufen, wo dann das ParentHandle und der Anzeigebereich übergeben wird. Dort zeichnet sich das dann hin.

Im Prinzip genau das was du auch machen willst. Du weisst wo es hin soll und hast auch den Bauplan, aber du weisst nicht wie du es bauen sollst und lässt das die DLL machen.

Ein Interface sollte man nicht nur auf die automatische Freigabe reduzieren. ;)
Und nicht jedes Interface kann sich auch selber wieder freigeben. Das hat etwas mit der Implementierung zu tun.

Der grosse Vorteil hier ist, dass du die Interface-Referenz einfach so Anwendungsübergreifend austauschen kannst. Nur bei den Rückgabewerten und Parametern muss man ein Auga darauf haben, dass man keine Delphi-Typen (wie z.B. string) verwendet. Alternativ bietet sich da z.B. der WideString an. Ist zwar langsamer aber hier safe, da der von Windows direkt verwaltet wird (darum ja auch langsamer).

Beispiele sollten sich da finden lassen. Wenn nicht, dann schau ich mal ... irgendwo habe ich noch so ein Beispiel rumfliegen.

[Uwe Raabe]

Zitat:

Zitat von Sir Rufo (Beitrag 1309685)

man könnte auch aus deinem Formular-Anzeiger einen PreviewHandler machen, der dann ganz einfach mit dem Windows Explorer funktioniert.

Da war doch mal was... Windows 7 Previews – the Delphi Way

[Harry Stahl]

Zitat:

Zitat von Sir Rufo (Beitrag 1309685)

Der PreviewHandler hat nichts mit Delphi zu tun, sondern sorgt dafür, dass du im Explorer eine Vorschau sehen kannst (z.B. von einer PDF-Datei)..

Geht das schon aktuell irgendwie oder meinst Du, es eher als theoretische Aussage, dass es gehen müsste?

Zitat:

Zitat von Sir Rufo (Beitrag 1309685)

Diese müssen sich entsprechend registrieren und man könnte auch aus deinem Formular-Anzeiger einen PreviewHandler machen, der dann ganz einfach mit dem Windows Explorer funktioniert.

Hier die Definition des Interfaces
https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx

Um diesen Preview (nach der Initialisierung) dann anzuzeigen, reicht es die Methode

Delphi-Quellcode:

SetWindow

aufzurufen, wo dann das ParentHandle und der Anzeigebereich übergeben wird. Dort zeichnet sich das dann hin.

Im Prinzip genau das was du auch machen willst. Du weisst wo es hin soll und hast auch den Bauplan, aber du weisst nicht wie du es bauen sollst und lässt das die DLL machen.

Wobei ich ja das Formular nicht nur anzeigen möchte, sondern damit interagieren will(wie im Video gezeigt), also beim Klick auf den Namen einer Ereignisprozedur an die Stelle im Source springen, Images aus der TImageList exportieren, (kommt noch: eine andere Seite eines TNotebooks anzeigen) etc.

Zitat:

Zitat von Sir Rufo (Beitrag 1309685)

Ein Interface sollte man nicht nur auf die automatische Freigabe reduzieren. ;)
Und nicht jedes Interface kann sich auch selber wieder freigeben. Das hat etwas mit der Implementierung zu tun.

Der grosse Vorteil hier ist, dass du die Interface-Referenz einfach so Anwendungsübergreifend austauschen kannst. Nur bei den Rückgabewerten und Parametern muss man ein Auga darauf haben, dass man keine Delphi-Typen (wie z.B. string) verwendet. Alternativ bietet sich da z.B. der WideString an. Ist zwar langsamer aber hier safe, da der von Windows direkt verwaltet wird (darum ja auch langsamer).

Beispiele sollten sich da finden lassen. Wenn nicht, dann schau ich mal ... irgendwo habe ich noch so ein Beispiel rumfliegen.

Ja, Beispiele, wie man ein Interface erzeugt, gibt es (hat mein Namensvetter Stahli hier ja auch mal gemacht). Ich müsste dann also statt der Form ein Interface erzeugen und zurückgeben. Und das kann man dann auch ohne die "TFont ist nicht gleich TFont" -Probleme in die aufrufende Form einfügen?

[Harry Stahl]

Danke Uwe, sieht interessant aus (was es nicht alles gibt), werde ich mir morgen mal in Ruhe ansehen. Insgesamt würde die Lösung aber wohl auch kein Zweizeiler sein. Und mir würde auch die Möglichkeit der Interkation fehlen.

[Aviator]

Zitat:

Zitat von Harry Stahl (Beitrag 1309687)

Zitat:

Zitat von Sir Rufo (Beitrag 1309685)

Der PreviewHandler hat nichts mit Delphi zu tun, sondern sorgt dafür, dass du im Explorer eine Vorschau sehen kannst (z.B. von einer PDF-Datei)..

Geht das schon aktuell irgendwie oder meinst Du, es eher als theoretische Aussage, dass es gehen müsste?

Na klar geht das jetzt schon. :wink: Klick einfach mal eine PDF Datei an und klick dann im Explorer auf die im Anhang im Screenshot markierte Fläche bei dir im Explorer (Windows 7 bzw. Windows 8.1).

[Harry Stahl]

Ja, bei PDF-Dateien oder anderen Dateien (Word, etc.) habe ich das auch schon gesehen, aber noch nie, dass im Explorer eine DFM-Datei als Vorschau angezeigt worden wäre.

[Aviator]

Zitat:

Zitat von Harry Stahl (Beitrag 1309690)

Ja, bei PDF-Dateien oder anderen Dateien (Word, etc.) habe ich das auch schon gesehen, aber noch nie, dass im Explorer eine DFM-Datei als Vorschau angezeigt worden wäre.

Nein das funktioniert ja auch nicht bzw. nur dann, wenn ein PreviewHandler für DFM Dateien im System registriert ist. Und genau das könntest du mit deinem Projekt machen. Du registrierst einen PreviewHandler im System und kannst hierdurch DFM Dateien in der Vorschau anzeigen. Und dafür brauchst du das von Sir Rufo genannte Interface.

[Harry Stahl]

Wie gesagt, ich könnte ich dann nicht mit dem Formular interagieren und eine Vorbedingung war, dass Delphi auf dem PC nicht installiert sein muss.

[Aviator]

Delphi muss auch nicht auf dem PC installiert sein. Ein PreviewHandler ist genau dafür da, auch Dinge anzeigen zu können, ohne das zwingend ein spezielles Programm dafür existieren muss. Stell dir dein Programm, das du gerade entwickelst, vor wie den Adobe Reader. Dieses Programm installierst du auf einem Rechner. Zugleich wird bei der Installation auch ein PreviewHandler im System registiert. Dieser bewirkt, dass du bereits im Explorer eine kleine Vorschau auf die (in deinem Fall) DFM Datei erhälst. Führst du dein Programm aus und öffnest die DFM Datei, kannst du dir bspw. noch alle Properties der Komponenten anzeigen lassen.

Eine abgespeckte Version deines Programmes wäre dann nur der PreviewHandler selbst. Somit hat ein Benutzer die Möglichkeit, ohne dein Programm und ohne Delphi eine Vorschau auf die DFM zu erhalten. Rein über die Vorschaufunktion des Explorers.

Ein weiterer Vorteil ist, dass jedes andere Programm, welches ebenfalls eine Vorschau von unterschiedlichen Dateitypen anzeigen will, ebenfalls auf den von dir im System registrierten PreviewHandler zugreifen kann (wie der Explorer es ja auch tut).

[Harry Stahl]

Gibt es denn nicht schon irgendeinen fertigen Preview-Handler, der DFM-Dateien im Explorer anzeigen kann?

Wäre doch eine tolle Sache, unabhängig davon, was aus meiner Geschichte wird. Das könnte doch so ziemlich jeder Delphi-Entwickler gut gebrauchen.

Wenn ich Dich richtig verstanden habe, könnte ich gleichfalls mein Programm mit einer Funktionalität ergänzen, die dann quasi als PreviewHandler im Explorer zur Verfügung steht. Das wäre natürlich durchaus auch eine interessante Sache.

[EWeiss]

Such doch mal im Net DFM - Viewer

gruss

[BUG]

Zitat:

Zitat von Harry Stahl (Beitrag 1309695)

Wenn ich Dich richtig verstanden habe, könnte ich gleichfalls mein Programm mit einer Funktionalität ergänzen, die dann quasi als PreviewHandler im Explorer zur Verfügung steht. Das wäre natürlich durchaus auch eine interessante Sache.

Ich sehe da 3. Richtungen.

1. allgemeinen PreviewHandler für Explorer schreiben
2. allgemeinen PreviewHandler (z.B. Pdf) auch in deinem Dateimanager unterstützen
3. interaktive Vorschau in deinem Dateimanager implementieren

1. nützt dir für deinen Dateimanager nicht so viel, ist aber für die meisten vermutlich praktischer. Ich denke mit 2. kann einen Haufen Formate erschließen, die du sonst nicht unterstützen könntest/wolltest. 3. ist das, was du gerade machst.

Zitat:

Zitat von EWeiss (Beitrag 1309696)

Such doch mal im Net DMF - Viewer

Ich persönlich finde da nichts brauchbares: DMF Viewer