Warum kann man Vererbung verhindern (csInheritable)?

**MaBuSE**

Zitat von Der_Unwissende:

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

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) ?

**Elvis**

Das hat eigentlich nix mit Vererbung zu tun. Denn dafür wäre die Sprache zuständig (Delphi hat IMO mitttlerweile abstrakte Klassen?).
Das Problem ist diese grauenvolle Art, in der IDE und Designer einem globale Variablen und unflexibel geteilte Referenzen aufzwingen.
Wenn du ein Form mit einem ActionManager 2-mal instanzierst, bekommst du auch die Actions 2-mal.
Innerhalb des Forms wird er das wohl noch richtig hinkriegen, nutzt du Actions außerhalb dieser Form fangen die Probleme natürlich an.
Ein anderer Grund kann sein, dass sie wohl Probleme haben, so komplexe Strukturen auch in Ableitungen noch reproduzierbar richtig aufzubauen. Wenn du vom Form ableitest und Action entfernst, hinzufügst, bestehende mit andere Handlern versiehst etc.
Vllt kommt dann ein Frankenstein-ActionManager raus, der nix Halbes und nix Ganzes ist.

Man kann halt nur soviel mit einem so einfach gestrickten RAD-Designer von 1995 anstellen, bevor man für 1m Weg 10m Umweg gehen muss.

**MaBuSE**

Zitat von Elvis:

Wenn du ein Form mit einem ActionManager 2-mal instanzierst, bekommst du auch die Actions 2-mal. Innerhalb des Forms wird er das wohl noch richtig hinkriegen, nutzt du Actions außerhalb dieser Form fangen die Probleme natürlich an.

Das ist ein anderes Problem.
Es ist ja durchaus möglich mehrere Instanzen zu verwenden.

zusammenfalten · markieren

Delphi-Quellcode:

			...

var

  a, b, c: TMyActionForm;

begin

  a := TMyActionForm.Create(Self);

  b := TMyActionForm.Create(Self);

  c := TMyActionForm.Create(Self);

  a.Show;

  b.Show;

  c.Show;

...

Die IDE versagt nur die Vererbung:

markieren

Delphi-Quellcode:

			...

type

  TMyForm = class(TMyActionForm)

...

Man beachte: Nur die IDE verweigert das mit der Fehlermeldung:

Zitat:

Fehler beim Erzeugen von Formular: Vererbung von 'Form2' nicht möglich. Es enthält eine Komponente 'AchtionManager1' ohne Vererbungsmöglichkeit.

Wenn man das *.pas und *.dfm von Hand erstellt (z.B. mit Notepad), geht es durchaus zur Laufzeit.

Zitat von Elvis:

Ein anderer Grund kann sein, dass sie wohl Probleme haben, so komplexe Strukturen auch in Ableitungen noch reproduzierbar richtig aufzubauen. Wenn du vom Form ableitest und Action entfernst, hinzufügst, bestehende mit andere Handlern versiehst etc.
Vllt kommt dann ein Frankenstein-ActionManager raus, der nix Halbes und nix Ganzes ist.

Warum dann aber auch bei TNotebook, TTabbedNotebook und TRibbon (bzw. TCustomRibbon)?
Ein TNotebook ist nun mal nicht sooo komplex.
Und viel interesannter ist die Frage, warum eine TActionList, die auch Actions beinhaltet, erlaubt ist.

Zitat von Elvis:

Man kann halt nur soviel mit einem so einfach gestrickten RAD-Designer von 1995 anstellen, bevor man für 1m Weg 10m Umweg gehen muss.

Das wird der Grund sein

Aber ich sehe die Frage noch nicht als beantwortet

**sgbSoftwareEntwickler**

Zitat von MaBuSE:

Aber ich sehe die Frage noch nicht als beantwortet

Sehe ich genau so ^^

Hab gerade folgendes probiert:

Ich habe eine Form erstellt, und einen Actionmanager darauf Platziert. Diesen ActionManager habe ich dann als Property dieser Form zur Verfügung gestellt.

Danach habe ich auf meinem Hauptformular eine Komponente (TActionMainMenuBar) gesetzt und diese dann mit dem Actionmanager vom anderen Formular verknüpft.

Die Idee dahinter: Ich muss die form, die den Actionmanager enthält nicht vererben, kann aber das Formular wo es verknüpft ist vererben.

Leider bin ich an dem Versuch gescheitert, Actions von diesem Actionmanager in mein TActionMainMenuBar einzufügen. Hat jemand ne Idee ob und wie das geht?

Den Code findet Ihr im Anhang

**MaBuSE**

Zitat von sgbSoftwareEntwickler:

Die Idee dahinter: Ich muss die form, die den Actionmanager enthält nicht vererben, kann aber das Formular wo es verknüpft ist vererben.
Leider bin ich an dem Versuch gescheitert, Actions von diesem Actionmanager in mein TActionMainMenuBar einzufügen. Hat jemand ne Idee ob und wie das geht?

Du kannst den ActionManager auf ein TForm oder TDataModule legen und quasi einfach verwenden.
Interesanterweise muß noch nicht mal die uses-Anweisung angepasst werden (kein uses Unit2 in der Unit1).
(Beispiel im Anhang)

Um die Menüs zu verknüpfen muß nur der ActionManager auf dem DataModule doppeltgeklickt werden.
Das Fenster ist nicht modal (also Show statt ShowModal) damit kannst Du dann auf das Formular wechseln, in dem Deine Action Toolbars sind und loslegen.
Anmerkung: TActionToolbars müssen von Hand auf das Form gelegt werden, da beim Anlegen aus dem TActionManager versucht würde, die Toolbar in das DataModul zu erzeugen.

Wenn das Dein Problem lösen sollte

**Hansa**

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

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 :

inherited frmArtNrAus: TfrmArtNrAus Erzeuge ich ein leeres Form, dann aber so :

object Form2: TForm2 Das vererbte Formular sieht weiter so aus :

zusammenfalten · markieren

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 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 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 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]