VCL Komponente unterschiedlich ableiten

[Ralle1]

Hallo,

Ich plane in einer größeren Anwendung grafische Elemente wie z.B. TPageControl durch modern wirkende Komponenten aus dem Hause TMS auszutauschen.
Der Austausch soll dabei möglichst zentral passieren. Im 1. Schritt habe ich eine leere Komponente erstellt: TMyPageControl 1:1 abgeleitet von TPageControl.
Dies habe ich zentral ausgetauscht und könnte diese nun im nächsten Schritt anderweitig ableiten (von TAdvOfficePager).

Um dies zentral zu steuern und erst nach kompletter Fertigstellung zu aktivieren, habe ich es mit einer bedingten Compilierung geschaltet. Sieht etwas so:

Delphi-Quellcode:

type
  {$IFDEF CLASSIC_CONTROL}
  TMyPageControl = class(TPageControl) 
  {$ELSE}
  TMyPageControl = class(TAdvOfficePager)
  {$ENDIF}
    { Private-Deklarationen }
    //...
  public
    { Public-Deklarationen }
    constructor Create(AOwner: TComponent);  override;
    destructor Destroy;
  end;

Nun meine Frage:
Kann man dies auch irgendwie zur Laufzeit ohne Compilerschalter hinbekommen?
Also praktisch ein PageControl dass sowohl TPageControl als auch TAdvOfficePager darstellen kann. Wie wäre Euer Ansatz zu dieser Lösung?

Besten Dank schonmal für eure Anregungen!

[himitsu]

Zitat von Ralle1:

Kann man dies auch irgendwie zur Laufzeit ohne Compilerschalter hinbekommen?

Jain.
Man kann eine Container-Typen erstellen, welcher dann intern den gewünschten Typen erstellt ... siehe z.B. TPicture (im TImage), welches in seinem .Graphic entweder ein TBitmap, TJpegImage, TPngImage oder sonstwas behandeln kann.


Zur Laufzeit brauchst du beide Typen (vollständig als eigene Typen deklariert)
und da könntest du dann beim Erstellen entscheiden von welchem Typ erstellt werden soll. (also der Container, wo dann das Gewünschte reingemacht wird)

Oder man nutzt ein Designtime-Package mit dem einem Typ und für's Kompilieren einen Quellcode mit dem anderen Typ, bzw. den anderen Typ in einem Runtime-Package.


Warum nicht direkt gleich den gewollten Typen verwenden?
Man kann natürlich mit einem Typen entwickeln und den später austauschen, aber auch nur, wenn die Property kompatibel sind.
Denn wenn die DFMs z.B. mit deim einem Typen erstellt wurden, dann knallt es, wenn man Diese dann mit dem anderem Typen versucht zu laden und er eines der Property nicht kennt.

[Ralle1]

Das sind so ziemlich genau auch meine Gedankengänge gewesen, nur hatte ich gehofft, dass mich jemand auf einen neuen Ansatz bringt.
Leiten wir also von dem gewünschten Typen ab, in meinem Beispiel also:

Delphi-Quellcode:

type
  TMyPageControl = class(TAdvOfficePager)

Nun noch eine Frage:
Komponente wie diese AdvOfficePager liefern eine Fülle an speziellen Properties.
Sollte ich irgendwann auf die Idee kommen, nun doch von einem Pagecontrol eines anderen Anbieters abzuleiten, habe ich den ganzen Kram in meinen dfm's verteilt.
Gibt es eine elegante Möglichkeit sicherzustellen, dass TMyPageControl auch nur die Properties verfügbar macht, die ich wirklich benutzen möchte und auch anderen Entwicklern am Projekt zur Nutzung erlauben möchte?

Ich möchte also in meiner Ableitung eine property unsichtbar machen, die im Vorfahr bereits als "published" veröffentlicht wurde.
Ein einfaches erneutes Definieren im private Bereich hilft leider nicht. Geht das?

[DeddyH]

Man kann Sichtbarkeiten nur erhöhen, verringern geht nicht. Das ist auch der Grund für die vielen TCustomXXX-Klassen in der VCL. Dort sind viele Eigenschaften protected deklariert, die abgeleiteten Klassen erhöhen die Sichtbarkeit dann zu public/published.

[sx2008]

In der Praxis hättest du mit deinem Ansatz mehr Arbeit als wenn du nur Formular für Formular die Standardkomponente durch deine neue Komponente ersetzt.
Wenn Delphi einen Macroprozessor wie z.B. LISP hätte dann liese sich sicher etwas machen.
So aber ist das direkte Ersetzen der Komponente der beste Weg.

[Ralle1]

Dem stimme ich komplett zu.

Wenn aber doch nur das Verringern von Sichtbarkeiten möglich wäre, könnte ich meine Komponente wesentlich kompakter machen!

[himitsu]

TCustomPageControl und eventuell gibt's auch einen passenden Vorfahren von TAdvOfficePager.

PS: stored False


[edit]
TCustomPageControl gibt es nicht.
Dafür zwar ein TCustomTabControl, als direkter Vorfahre von TPageControl, aber dort fehlen noch viele Eigenschaften und Methoden, welche erst direkt in TPageControl implementiert wurden.