Spezieller TFrame

[Schokohase]

Was geht ist folgendes:

Wir erstellen uns manuell eine Ableitung von TFrame :

Delphi-Quellcode:

unit CustomFrameApp.Frames.MyBaseFrame;

interface

uses
  Vcl.ExtCtrls,
  Vcl.Forms;

type
  TMyBaseFrame = class(TFrame)
  private
    FIcon: TImage;
  published
    property Icon: TImage read FIcon write FIcon;
  end;

implementation

end.

Dann erstellen wir uns ein neues TFrame wie gehabt und verändern den Source leicht:

Delphi-Quellcode:

unit CustomFrameApp.Frames.MyFrame;

interface

uses
  Winapi.Windows,
  Winapi.Messages,
  System.SysUtils,
  System.Variants,
  System.Classes,
  Vcl.Graphics,
  Vcl.Controls,
  Vcl.Forms,
  Vcl.Dialogs,
  // die Unit mit dem Vorgänger-Frame
  CustomFrameApp.Frames.MyBaseFrame;

// Umbiegen der Klasse TFrame auf die gewünschte Klasse
type
  TFrame = CustomFrameApp.Frames.MyBaseFrame.TMyBaseFrame;

type
  TMyFrame = class(TFrame)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

implementation

{$R *.dfm}

end.

[Schokohase]

Zitat von Der schöne Günther:

Nur wenn man auf Zugriffsverletzungen und ähnliches steht.

Nie Interface- und TObject-basierte Referenzierung mischen

So ein Unsinn ... in diesem Fall ist das genauso gefährlich als wenn ich die TFrame-Instanz direkt übergebe.

Das Problem, auf welches du dich beziehst ist dort, wo die Referenzzählung die Instanz aus dem Speicher kicken kann, da sollte man nur noch per Interface auf die Instanz zugreifen.

[hzzm]

Zitat von Schokohase:

Delphi-Quellcode:

// Umbiegen der Klasse TFrame auf die gewünschte Klasse
type
  TFrame = CustomFrameApp.Frames.MyBaseFrame.TMyBaseFrame;

Interessant, und der FormDesigner bei F12 frisst das Teil dann trotzdem wie gewohnt?
Muss ich mal testen. Mein Loesungsweg war dann doch ne Ecke umstaendlicher...

[hzzm]

Zitat von Der schöne Günther:

Nur wenn man auf Zugriffsverletzungen und ähnliches steht.

Nie Interface- und TObject-basierte Referenzierung mischen

Soweit ich das verstanden habe, kriegst Du das Problem nur, wenn Du von TInterfacedObject erbst. Sonst findet keine Referenzgezaehlte Destruktion statt.

[Schokohase]

Das Problem ist, dass die IDE nach dem Namen der Vorgänger-Klasse schaut, wenn der Vorgänger keine DFM Datei hat.

Wenn dann der Name der Vorgänger-Klasse <> TFrame dann wird das Dingen wie ein TForm behandelt. Das ist das ganze Geheimnis.

Auf das gleiche Problem trifft man übrigens auch bei TDataModule (aber wahrscheinlich seltener, weil man da nicht so viel ableitet).

[peterbelow]

Zitat von hzzm:

Wenn ich also wie man es normal vermuten wuerde, einfach eine neue Klasse von TFrame ableite und ein Member Icon hinzufuege, war nicht moeglich, in der IDE im Code TMyCoolFrame = class(TFrame) abzuaendern in TMyCoolFrame = class(TMyBaseFrame), so dass bekannt ist, dass ein Icon enthalten ist und gleichzeitig trotzdem das Editieren des TFrame im FormEditor moeglich ist (F12).

Kurz gesagt wie in Post 1 geschrieben.
"war nicht moeglich", weil ich es mittlerweile geschafft habe. Was fuer ein Teufelsritt, ich weiss gar nicht, warum die IDE sich da so scheut

Ich hab dein Problem offenbar nicht richtig verstanden. Dir fehlte wirklich nur eine Kleinigkeit zum Erfolg: Bei Designerklassen fängt das DFM-File mit dem Keyword "object" an, wenn direkt von TForm, TFrame, oder TDatamodule abgeleitet wird. Wenn von einer anderen Klasse abgeleitet wird, die schon ein DFM-File hat (dein Fall) muss das DFM-File der abgeleiteten Klasse aber mit "inherited" anfangen, nicht mit "object". Wenn Du also den Ancestor im Editor manuell änderst mußt Du danach mal kurz "view form as text" machen, das erste object in inherited ändern, und dann wieder in den Form-View zurück gehen.

[hzzm]

Zitat von peterbelow:

Ich hab dein Problem offenbar nicht richtig verstanden. Dir fehlte wirklich nur eine Kleinigkeit zum Erfolg: Bei Designerklassen fängt das DFM-File mit dem Keyword "object" an, wenn direkt von TForm, TFrame, oder TDatamodule abgeleitet wird. Wenn von einer anderen Klasse abgeleitet wird, die schon ein DFM-File hat (dein Fall) muss das DFM-File der abgeleiteten Klasse aber mit "inherited" anfangen, nicht mit "object". Wenn Du also den Ancestor im Editor manuell änderst mußt Du danach mal kurz "view form as text" machen, das erste object in inherited ändern, und dann wieder in den Form-View zurück gehen.

Genau, das war die Loesung, auf die ich auch nach ewigem getanze gekommen bin, mit einem Wermutstropfen:

Es war notwendig, die TFrame-Abgeleitete Basisklasse, die man TMyCoolFrame zur Ableitung reicht, vollstaendig leer zu erstellen, dann als Basisklasse anzugeben.
Wenn dieses Konstrukt zusammen mit dem "inherited" in der .dfm statt "object" mal steht, kann man in der Basisklasse aendern, was man will.

[peterbelow]

Zitat von hzzm:

Genau, das war die Loesung, auf die ich auch nach ewigem getanze gekommen bin, mit einem Wermutstropfen:

Es war notwendig, die TFrame-Abgeleitete Basisklasse, die man TMyCoolFrame zur Ableitung reicht, vollstaendig leer zu erstellen, dann als Basisklasse anzugeben.
Wenn dieses Konstrukt zusammen mit dem "inherited" in der .dfm statt "object" mal steht, kann man in der Basisklasse aendern, was man will.

Es ist definitiv nicht nötig, mit einer leeren Basisklasse anzufangen. Die IDE hat aber ein Problem, wenn man eine Instanz eines Frames auf einem Form hat, daran dort etwas ändert, und danach dann an der Frameklasse selbst was ändert. Die IDE erkennt das nicht immer korrekt, mitunter muß man manuell im Designer aus dem Kontextmenu für das eingebettete Frame ein "revert to inherited" machen, damit die Änderungen an der Frameklasse übernommen werden. Visual form inheritance hat so seine Macken...

[Rollo62]

Zitat von Der schöne Günther:

Nur wenn man auf Zugriffsverletzungen und ähnliches steht.

Nie Interface- und TObject-basierte Referenzierung mischen

Das mache ich auch nicht, und habe keinerlei Probleme damit.
Der Zugriff ist dann natürlich ausschliesslich über Interfaces.

[Rollo62]

Zitat von hzzm:

Zitat von Schokohase:

Delphi-Quellcode:

// Umbiegen der Klasse TFrame auf die gewünschte Klasse
type
  TFrame = CustomFrameApp.Frames.MyBaseFrame.TMyBaseFrame;

Hallo Schokohase,

ja, das ist eine super Lösung.
Ich benutze das "Umbiegen" in ähnlicher Form an einigen Stellen.

Ich frage mich wie das "Umbiegen" als Fachbegriff heisst, weil ich nenne das für mich manchmal Unit-Forwarding.

Hat diese Methode vielleicht einen klaren Namen ?