Warum kann man Vererbung verhindern (csInheritable)?

[MaBuSE]

Zitat:

Zitat von Der_Unwissende

Zitat:

Zitat von MaBuSE

ich habe mal eine grundsätzliche Frage:
Warum ist es möglich zu verhindern, dass ein Formular abgeleitet werden kann?

Hi,
ist eigentlich eine wirklich interessante Frage. Hab noch gar nicht drüber nachgedacht, dass Delphi ja auch diese Funktionalität bietet. An sich gibt es ja auch in anderen Sprachen die Möglichkeit eine Klasse nicht erweiterbar zu deklarieren. In Java wäre eine solche Klasse dann mit dem Schlüsselwort final versehen.

Nicht die Komponente ist final, sondern das Form, auf dem so eine Komponente liegt, die diese Eigenschaft hat!

Man packe eine TActionManager auf das Form und das Form ist nicht mehr vererbbar.

Man kann trotzdem noch von TActionManager ableiten.

Zitat:

Zitat von Jelly

Also ich vermute, dass es verschiedene Komponenten gibt, die nur einmal pro Anwendung erlaubt sind, oder genutzt werden sollen (XPManifest, TDatabase usw.).

Grad bei TDatabase darf pro Anwendung nur eine TDatabase pro Datenbank definiert sein. Wenn Du jetzt aber von einer Form erbst, die eine TDatabase implementiert, so hast du zwangsläufig 2 identische Verbindungen.

Dieser Artikel bestätigt auch meinen Verdacht... Mann, bin ich gut :mrgreen:

Im obigen Artikel steht

As a result of form inheritance being introduced in Delphi 2.0, the ComponentStyle property was added to the TComponent class. This property represents a set of style attributes that govern how a component behaves. In particular, the set can hold two possible styles: csInheritable and csCheckPropAvail.

The csInheritable style indicates that the component can be inherited by a descendent form type. For a form to be inheritable (that is, serve as an ancestor to another form), all components on the form must have the csInheritable style set. If any of the components do not include this style, then Delphi will display an error when you attempt to create a new form descendant. The TComponent class sets the csInheritable style by default in its constructor, and for most circumstances, you will not need to change it. However, it may be necessary to remove this style because of how the component is implemented. For example, the TDatabase component class removes this style because there can only be one Database component per database in an application. If this style is not removed, then a form and its ancestor could be used in the same application, thereby causing the Database component on each form to reference the same physical database.

Das ist aber definitiv falsch !!! Man sollte nicht alles glauben, was im Internet steht. ;-)
TDatabase auf ein TForm und ich kann es trotzdem vererben !!!
(Das habe ich gerade in D7 getestet.)
In Delphi 7 haben nur die 3 oben angegebenen Komponenten diese "Ich will nicht, dass mein OwnerForm vererbt wird" Eigenschaft implementiert.
Das kann es also nicht sein.

Auch kann ich mehrere TActionManager auf ein Formular legen.
Das kann es also auch nicht sein.

Selbst das XPManifest kannst du auf beliebige Formulare beliebig oft legen.
Diese Komponente ist nur ein Dummy.
Das Wichtige ist das {$R WindowsXP.res} in der XPMan Unit.
Und das wird nur einmal pro App eingebunden, da die Unit XPMan ja nur einmal in die App gelinkt wird.

Trotzdem Danke für Eure Gedanken ;-)

Hat jemand weitere Ideen (oder gar das Wissen) ?

[Hansa]

Zum "Warum ?" kann ich auch nicht viel sagen, aber eventuell einige Hinweise liefern.

Zitat:

Zitat von MaBuSE

..Nun ändern wir die Peoject1.dpr wie folgt ab:
...
Mit dieser Technik kann man sich Formulare erstellen, die eine gewisse Basisfunktionalität haben.
Diese können dann in den Anwendungen verwendet werden, ohne das man alles noch mal neu programmieren muß.
Änderungen an den Basisformularen sind auch sofort in allen abgeleiteten Formularen (nach einem Recompile der Programme) verfügbar.

Super !!!
Genau das will ich haben.

Eine Basisfunktionalität in seine Formulare einzubauen ist der Sinn der Objektablage. Man kann das zwar auch von Hand erledigen (wie hier), aber das ist nicht zu empfehlen wegen zu vieler Quereffekte. Denn : wird es richtig gemacht, so muß man nicht nur die DPR/PAS ändern, sondern auch die DFMs und anderes. Wenn ich ein Formular vererben will, dann sieht das so aus :

Delphi-Quellcode:

inherited frmArtNrAus: TfrmArtNrAus

Erzeuge ich ein leeres Form, dann aber so :

Delphi-Quellcode:

object Form2: TForm2

Das vererbte Formular sieht weiter so aus :

Delphi-Quellcode:

  inherited pnlOben: TPanel
    Height = 161
    object ckbAlpha: TCheckBox
      Left = 296
      Top = 120
      Width = 129
      Height = 17
      Caption = 'alphabetisch sortieren'
      TabOrder = 1
    end
    object btnStart: TButton

Das Panel "pnlOben" ist mit allen Eigenschaften vom Vorfahr-Formular geerbt. Die Checkbox darauf wurde erst jetzt mit diesem Formular eingeführt. Vererbe ich es weiter, so stehen in der DFM nur noch die geänderten Sachen drin. Soll nun irgendwo die Vererbung unterbrochen werden, so könnte es eventuell schon genügen ein inherited wegzulassen. Ein Blick in die DFM eines Formulars, das nicht mehr vererbt werden kann sollte das klären. Oder mal dasselbe Form per Objektablage vererben und nicht von Hand. Da sind sicherlich Unterschiede zu bemerken.

[MaBuSE]

Zitat:

Zitat von Hansa

Eine Basisfunktionalität in seine Formulare einzubauen ist der Sinn der Objektablage.

Wenn Du die Objektablage verwendest, und beim Einfügen nicht "kopieren" oder "verwenden" sondern "Vererben" anklickst, machst Du genau das selbe wie ich hier im Beispiel.
Deine DFM-Dateien sehen genau so aus.
Sicherlich werden die Basisformulare in die Objektablage kommen, aber wenn dort ein TActionManager enthalten ist, kann man auch nicht vererben!!!
Das ist die selbe Technologie.
Diese verwenden wir ja auch schon einige Jahre ;-)
Ich habe es im Beispiel nur ohne die Objektablage gemacht um es nicht unnötig zu komplizieren.

Zitat:

Zitat von Hansa

Man kann das zwar auch von Hand erledigen (wie hier), aber das ist nicht zu empfehlen wegen zu vieler Quereffekte. Denn : wird es richtig gemacht, so muss man nicht nur die DPR/PAS ändern, sondern auch die DFMs und anderes. Wenn ich ein Formular vererben will, dann sieht das so aus ...

Welche Quereffekte?
Es wird doch die selbe Technologie verwendet.
Die Änderungen an den DFM Dateien macht die Delphi IDE doch von selbst.

Das Kopieren oder Verwenden in der Objektablage umgeht zwar das Problem, aber ich verliere dann auch die Möglichkeiten.

Ich will ein SDI- sowie ein MDI-Basisformular haben, das in allen Applikationen verwendet werden kann.
Änderungen am Basisformular sollen sich direkt auch auf die abgeleiteten Formulare auswirken (beim nächsten kompilieren).
Ich möchte ein MDI Child Basisformular haben, das von allen MDI-Applikationen verwendet wird.
In dem MDI Child sind auch abstrakte Methoden enthalten, die in der Applikation implementiert werden müssen.
z.B. procedure TMDIChild.SaveData;
Wenn im Menü Speichern gedrückt wird, wird automatisch SaveData des MDI Fensters aufgerufen.
Außerdem möchten wir bestimmte Merkmale in den MDI Child Fenstern über Interfaces realisieren, um sie im Framework besser ansprechen zu können.

Das klappt auch soweit sehr gut. Und ist wie gesagt schon seit Jahren hier im Einsatz.

Die Applikation soll nun eine neue Optik bekommen und so werden gerade die Basisformulare angepasst.

ABER es kann z.B. kein TActionManager verwendet werden.
Egal ob mit oder ohne Objektablage.

Zitat:

Zitat von Hansa

Das Panel "pnlOben" ist mit allen Eigenschaften vom Vorfahr-Formular geerbt. Die Checkbox darauf wurde erst jetzt mit diesem Formular eingeführt. Vererbe ich es weiter, so stehen in der DFM nur noch die geänderten Sachen drin. Soll nun irgendwo die Vererbung unterbrochen werden, so könnte es eventuell schon genügen ein inherited wegzulassen. Ein Blick in die DFM eines Formulars, das nicht mehr vererbt werden kann sollte das klären. Oder mal dasselbe Form per Objektablage vererben und nicht von Hand. Da sind sicherlich Unterschiede zu bemerken.

Das ist doch normal bei der Objektorientierten Programmierung.
Du kannst ja auch nicht die Vererbungskette von Objekten trennen.
Wie willst Du das denn machen. Die DFM-Datei ist ja nur eine Resource, die in die Unit mit {$R *.dfm} eingebunden wird.
Die IDE sorgt im Normalfall dafür, das immer das Richtige drinnsteht.

Warum sollte also die Vererbung unterbrochen werden?

Ich versteh Dein Problem nicht.


Aber danke für den Hinweis ;-)


[edit]@all:
ps: bitte in diesem Thread keine Diskussion über den Sinn und Zweck von Interfaces und abstrakten Methoden führen, dafür gibt es schon andere Threads ;-)
[/edit]

[MaBuSE]

Zitat:

Zitat von MaBuSE

bitte in diesem Thread keine Diskussion über den Sinn und Zweck von Interfaces und abstrakten Methoden führen, dafür gibt es schon andere Threads ;-)

Das solte aber nicht bedeuten, das niemand mehr etwas schreibt.

[MaBuSE]

Zitat:

Zitat von MaBuSE (Beitrag 606756)

Zitat:

Zitat von MaBuSE

bitte in diesem Thread keine Diskussion über den Sinn und Zweck von Interfaces und abstrakten Methoden führen, dafür gibt es schon andere Threads ;-)

Das solte aber nicht bedeuten, das niemand mehr etwas schreibt.

Nach 3 Jahren kann man mal einen *PUSH* wagen ;-)

Das Problem ist zwar nicht mehr aktuell, aber eine Antwort würde mich schon interessieren.
:glaskugel:

[sgbSoftwareEntwickler]

Zitat:

Zitat von MaBuSE (Beitrag 1026310)

Zitat:

Zitat von MaBuSE (Beitrag 606756)

Zitat:

Zitat von MaBuSE

bitte in diesem Thread keine Diskussion über den Sinn und Zweck von Interfaces und abstrakten Methoden führen, dafür gibt es schon andere Threads ;-)

Das solte aber nicht bedeuten, das niemand mehr etwas schreibt.

Nach 3 Jahren kann man mal einen *PUSH* wagen ;-)

Das Problem ist zwar nicht mehr aktuell, aber eine Antwort würde mich schon interessieren.
:glaskugel:

Dem Kann ich nur zustimmen: Habe bisher weder Gründe noch eine Lösung gefunden. Stehe vor dem selbe Problem mit TActionManager und TRibbon

[SirThornberry]

Kann es sein das all diese Komponenten deprecated sind? Dann würde es Sinn machen. So verhindert man das neue Formulare auf veralteten Komponenten aufbauen und zwingt somit den Programmierer auf andere Komponenten auszuweichen.

[sgbSoftwareEntwickler]

Zitat:

Zitat von SirThornberry (Beitrag 1092211)

Kann es sein das all diese Komponenten depricated sind? Dann würde es Sinn machen. So verhindert man das neue Formulare auf veralteten Komponenten aufbauen und zwingt somit den Programmierer auf andere Komponenten auszuweichen.

Leider muss ich eine zugeben, dass ich deprecated und seine anwendung nicht kenne.

Ich habe Vorhin mal etwas ausprobiert:

Ich habe mir eine eigene Klasse TMeinRibbon von TRibbon abgeleitet und mir daraus eine komponente gebaut:

Code:

unit MeinRibbon;

interface

uses
  Ribbon, Classes, ActnMan;

type
  TMeinRibbon = class(TRibbon)
  public
    constructor Create(AOwner: TComponent); override;
  end;

implementation

procedure Register;
begin
  RegisterComponents('Test', [TMeinRibbon]);
end;


{ TMeinRibbon }

constructor TMeinRibbon.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FComponentStyle := FComponentStyle + [csInheritable];
end;

Danach habe ich ein Formular erstellt und MeinRibbon1 darauf gesetzt.

Wenn ich das Ganze per Delphi vererbe (Neu -> Vererbare Elemente ...) haut es mir meine komplette konfiguration von MeinRibbon1 zusammen.
Wenn ich es per Hand vererbe (Neu -> Formular ... TForm1 = class(TMeinGrundFormular) <- per Hand im Quellcode), funktioniert soweit alles, aber ich sehe die Ribbonbar nur zur Laufzeit und hab nur Bedingt Zugriff auf die Ribbonbar.

Ich spiele noch mit den Möglichkeiten und versuche das ganze auch für den TActionManager

Falls Ihr eine andere Idee habt, her damit!

Ich werde euch auf dem Laufenden halten.

[HeikoAdams]

Zitat:

Zitat von SirThornberry (Beitrag 1092211)

Kann es sein das all diese Komponenten deprecated sind? Dann würde es Sinn machen. So verhindert man das neue Formulare auf veralteten Komponenten aufbauen und zwingt somit den Programmierer auf andere Komponenten auszuweichen.

Denkbar, aber bei TRibbon zumindest eher unwahrscheinlich.

Dafür, einer Komponente die Vererbung zu verbieten, fällt mir nur ein Szenario ein: Als Anbieter von closed source Komponenten könnte man durchaus ein (wirtschaftliches) Interesse daran haben, das Dritte die Komponente nicht erweitern können.

[MaBuSE]

Zitat:

Zitat von SirThornberry (Beitrag 1092211)

Kann es sein das all diese Komponenten deprecated sind? Dann würde es Sinn machen. So verhindert man das neue Formulare auf veralteten Komponenten aufbauen und zwingt somit den Programmierer auf andere Komponenten auszuweichen.

Die Komponenten sind nicht "veraltet".
Weder bei Delphi 7 (1. Beitrag) noch bei der aktuellen XE.

Zitat:

Zitat von HeikoAdams (Beitrag 1092217)

Dafür, einer Komponente die Vererbung zu verbieten, fällt mir nur ein Szenario ein: Als Anbieter von closed source Komponenten könnte man durchaus ein (wirtschaftliches) Interesse daran haben, das Dritte die Komponente nicht erweitern können.

Es geht nicht darum die Vererbung einer Komponente zu verbieten.
Welchen Sinn das hat, ist mit klar. (sealed Objects)

Es geht darum, dass eine Komponente verhindert das das Owner/Parent-Formular nicht mehr vererbt werden kann.

Also nochmal:

• Alle möglichen Komponenten auf Form -> Form kann vererbt werden.
• Eine der 3 problematischen Komponente (z.B. TActionManager) auf Form -> Form kann nicht mehr vererbt werden.