Spezieller TFrame

[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...