Warum kann man Vererbung verhindern (csInheritable)?

[MaBuSE]

Zitat von HeikoAdams:

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.

Darum geht es ja gar nicht.
Es wird nicht das Ableiten (Vererben) der Komponenten verhindert. Das ist weiterhin möglich.
Es wird verhindert, das das TForm, auf dem die Komponente liegt vererbt werden kann.

Im 1. Beitrag es es genau erklärt.

[MaBuSE]

Zitat von MaBuSE:

Wenn man nun eine Komponente auf das TForm1 legt, die in ComponentState kein csInheritable hat, dann kann ich das Formular nicht mehr vererben.

Es gibt 3 Komponenten bei denen das der Fall ist.

• TActionManager (bzw. TCustomActionManager)
• TNotebook
• TTabbedNotebook

Ich habe gerade mal in Delphi XE nachgeschaut:

Es gibt in Delphi XE 4 Komponenten bei denen das der Fall ist.

• TActionManager (bzw. TCustomActionManager)
• TNotebook
• TTabbedNotebook
• TRibbon (bzw. TCustomRibbon)

TRibon wurde ja schon von sgbSoftwareEntwickler entdeckt
Ich wollte nur sichergehen, dass nicht noch mehr Komponenten davon infiziert wurden.

[sgbSoftwareEntwickler]

Das Problem besteht nach wie vor. Ich will die Ribbonbar (mit Actionmanager) in einem bestehenden Grundformular einführen. Ich bin nach wie vor für Ideen offen

[yörsch]

zu TNotebook und Vererbung:
wir nutzen TNotebook intensive! und vermeiden rein aus praktischen Gründen eine Vererbung eines solchen Fensters.

Mann stelle sich vor es gibt ein Fenster mit einem TNotebook auf dem sind 10 Pages.
Insgesamt sind dort Hunderte von Controls drauf. Wenn ich jetzt im Basis Fenster ein
paar Veränderungen mache, hab ich in den abgeleiteten Fenster meine mühe alles wieder
glatt zu ziehen damit alles wieder gut funktioniert...

Schon besser sind Frames die ich dann auf die Seiten des TNotebook plaziere.
---

Und, wenn ich in großen Teams arbeite will ich verhindern das nicht jede Nase ungefragt wichtige, komplizierte Klasse vererbt...

[sgbSoftwareEntwickler]

Aus der Delphi Hilfe:

Zitat von DelphiHilfe:

TNotebook wird aus Gründen der Abwärtskompatibilität bereitgestellt. In neuen Anwendungen sollte TPageControl verwendet werden.
...
TTabbedNotebook dient der Rückwärtskompatibilität. In neuen Anwendungen sollte TPageControl verwendet werden.

Das csInheritable Problem kann man ja bei TNotebook und TTabbedNotebook mehr oder weniger leicht umgehen. Natürlich sollte man vor der Umsetzung Nutzen und Aufwand gegeneinander aufwiegen.

Zitat von yörsch:

zu TNotebook und Vererbung:
...
Mann stelle sich vor es gibt ein Fenster mit einem TNotebook auf dem sind 10 Pages.
Insgesamt sind dort Hunderte von Controls drauf. Wenn ich jetzt im Basis Fenster ein
paar Veränderungen mache, hab ich in den abgeleiteten Fenster meine mühe alles wieder
glatt zu ziehen damit alles wieder gut funktioniert...

Dann hast du meiner Meinung nach den Sinn eines Grundformulares nicht verstanden. Und was hindert Dich daran, deine Frames auf das Grundformular zu setzten? Wenn du sauberes Design hast, solltest du nie Anzeigeprobleme bekommen. Ich zum Beispiel nutze ein Navigationsframe auf das alle anderen Frames kommen. ist für kleine Anwendungen zwar Aufwendig, dafür umso angenehmer wenn man viele Menüpunkte oder Tabs abbilden möchte. Und das Navigationsframe platziere ich auf mein (abgeleitetes) Grundformular. Das abgeleitete Grundformular fasse ich nach Möglichkeit gar nicht an. Höchstens um Menüpunkte ein / auszublenden.

Zitat von yörsch:

Und, wenn ich in großen Teams arbeite will ich verhindern das nicht jede Nase ungefragt wichtige, komplizierte Klasse vererbt...

Nochmal, hier geht es nicht um sealed Klassen, sondern Komponenten die das Vererben des Parentformulars verhindern.
Und gerade wenn du in großen Teams arbeitest, ist doch ein Grundformular hilfreich, da jeder mit der selben Basis arbeitet / arbeiten muss und somit CorpIdent Geschichten und wichtige (geänderte, neue und/oder entfernte) Funktionalitäten sofort in allen vom Grundformular vererbten Projekten nach der nächsten Kompilierung greifen.

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

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:

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

[MaBuSE]

Versucht mal einen TActionManager auf einen TFrame zu legen