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