Warum kann man Vererbung verhindern (csInheritable)?

[sgbSoftwareEntwickler]

Zitat:

Zitat von MaBuSE (Beitrag 1110650)

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

Jo, danke. Da hat man eine passable Idee und scheitert an seiner eigenen Blindheit. Das dass Fenster modal ist... darauf wäre ich gar nicht gekommen xD

Zitat:

Zitat von MaBuSE (Beitrag 1110651)

Versucht mal einen TActionManager auf einen TFrame zu legen :twisted:

Der war gut :thumb:

[MaBuSE]

Und wieder ist ein Jahr vergangen und immer noch keine Antwort in Sicht :?

[himitsu]

Hab zwar keine Antwort auf die Frage, also nach dem Warum und so.

Was ich sagen kann, daß auch noch die Ribbons davon betroffen sind, aber die nutzt ja eh Keiner.

Und die Prüfung auf dieses Vererbungszeugs scheint direkt in der Delphi-IDE eingebaut zu sein, so daß man daran auch nicht so leicht was ändern kann.

Was aber eventuell ginge,

Delphi-Quellcode:

type
  TActionManager2 = class(TActionManager)
  public
    constructor Create(AOwner: TComponent); override;
  end;

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

procedure Register;

implementation

procedure Register;
begin
  RegisterComponents('Standard', [TActionManager2]);
end;

[Rainer Wolff]

Zitat:

Zitat von MaBuSE (Beitrag 1181265)

Und wieder ist ein Jahr vergangen und immer noch keine Antwort in Sicht :?

inzwischen sind weitere 12 Jahre vergangen, und ich bin über das selbe Problem gestolpert. Ich benutze eine ComPort Library, die etwa ebenso alt ist.
http://comport.sf.net/

Da ist dieses Flag csInheritable ebenfalls ausgeblendet und ich suche den Sinn dahinter.

Die Komponente wurde irgendwann im Grundprojekt ausgetauscht, weil die noch ältere Comport-Komponente, die bis dahin im Einsatz war, nicht mehr wollte (an die Gründe kann ich mich nicht mehr entsinnen).

Vom Grundprojekt abgeleitet gibt es aber ebenfalls noch Projekte, die ähnlich sind und Grundformulare erben und ggf. modifizieren.

An eines dieser abgeleiteten Projekte muss ich jetzt drangehen und habe das selbe Problem.

Ich tendiere dazu, die entsprechende Programmzeile der ComPort-Komponente einfach flach zu legen, wollte aber vorher noch dazu recherchieren, ob das Vererbungsverbot einen tieferen Sinn hat.

[himitsu]

Die Komponente nicht auf der Form, sondern erst im OnCreate erstellen, wäre auch noch eine Lösung.

[MaBuSE]

Zitat:

Zitat von himitsu (Beitrag 1543152)

Die Komponente nicht auf der Form, sondern erst im OnCreate erstellen, wäre auch noch eine Lösung.

oder man verwendet nicht die IDE,sondern Notepad ;)

Zitat:

Zitat von MaBuSE (Beitrag 1110504)

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

Erstaunlich: Ich habe den Thread 2006 erzeugt. Aber es scheint immer noch ab und zu jemanden zu interessieren. :thumb:

[Rollo62]

Ich weiss generell nicht, ob das Vererben von TForm nicht generell ein Ruf nach Ärger und Problemen ist.
Zum Beispiel eine Basisform mit TPanel usw. und dann in der abgeleiteten Form Komponenten in diese werfen.
Theoretisch sollte das kein Problem sein ...
Ich traue dem IDE Designer nur bedingt und der kommt schon bei TFrames im Designer aus dem Ruder, weshalb ich TFrames nur per Runtime nutze.
Warum sollte das bei TForm anders sein?

Ich verstehe die Motivation und wünsche mir das auch, aber per Runtime ist sowas viel sicherer lösbar.

[Medium]

Zumindest unter D2007 hatte ich damit bisher keine Probleme. Unser damaliges Hauptprodukt (welches ich noch immer aktiv pflege) basiert quasi komplett auf einer abgeleiteten TForm-Klasse. Dort sind allerdings keine weiteren Komponenten zugefügt, sondern ein Thread, der für jede Instanz im Hintergrund Dinge erledigt (und ein paar weitere nicht-visuelle Properties).
Daher ist die Benutzung vielleicht auch etwas simpler: Einfach nach Erstellen eines neuen Forms im Code-Editor die Klasse von TForm auf TMyForm ändern, und man kann sogar direkt ohne das Projekt neu zu öffnen weiter machen. Hundertfach im Einsatz - also nicht 100x das gleiche Programm, sondern in Summe ca. hundert individuelle Formulare. (Ist für eine Steuerungsvisualisierung ähnlich Siemens WinCC.)

[MaBuSE]

Zitat:

Zitat von himitsu (Beitrag 1181276)

Delphi-Quellcode:

  FComponentStyle := FComponentStyle + [csInheritable];

Wäre so was nicht auch mit einem Class Helper zu lösen?
Dann müsste man "nur" eine weitere Unit einbinden ;)

Wenig elegant, aber ...

Ich komme leider nicht dazu es zu Testen.
Für die, die nicht wissen was ein ClassHelper ist und was man damit machen kann:
hier ein kleines Tutorial von mir ;)
https://www.delphipraxis.net/164041-...ntdataset.html

[himitsu]

Nee, da es dort ja kein Override gibt.
und somit kennt der DFM-Reader das Create des Helpers nicht.