Propertys in einer abgeleiteten Klasse "unsichtbar" machen

[Corth]

Hallo

wer weiß wie man Propertys, welche per "published" in einer Vorgängerklasse sichtbar gemacht wurden, in einer abgeleiten Klasse wieder verbergen kann. Der Zweck soll sein, in einer Komponente zur Entwurfszeit (IDE), Eigenschaften im Objektinspektor, die in der "abgeleiteten" Komponente keinen Sinn machen zu verbergen. Dies dürfte sicher auch von allgemeinem Interesse sein.

Gruß ulli

PS. Betrifft Delpi 7

[marabu]

Herzlich willkommnen in der Delphi-PRAXiS, Ulli.

Kurze Antwort: vergiss es. Begründung:

Borland schreibt zum Thema Sichtbarkeit von Klassenelementen

Sie können die Sichtbarkeit eines Elements in einer untergeordneten Klasse durch Redeklarieren erhöhen, jedoch nicht verringern. So kann beispielsweise eine protected
-Eigenschaft in einer abgeleiteten Klasse als public deklariert werden, nicht aber als private. Außerdem können published-Elemente nicht zu public-Elementen gemacht werden.

Freundliche Grüße vom marabu

[mkinzler]

Hallo Ulli,

Zitat:

Eigenschaften im Objektinspektor, die in der "abgeleiteten" Komponente keinen Sinn machen zu verbergen. Dies dürfte sicher auch von allgemeinem Interesse sein.

Der Grund, warum es nicht geht, ist das die Beziehung IS-A zwischen der abgeleiteten Klasse und der Superklasse besteht. Nimmst du nun eine Eigenschaft weg, gilt diese Beziehung nicht mehr.

[Union]

Hallo,

Du könntest versuchen, die Klassen weiter "aufzudröseln". Also eine Basisklasse (TCustomxxx) von der sich dann mehrere Zweige ableiten (TCustomEditablexxx, TCustomNotEditablexxx). Setzt natürlich voraus, dass dies dann auch klar abgrenzbar ist.

[Corth]

Hallo marabu,
Besten Dank für die schnelle Reaktion. Das habe ich schon vermutet.

Beim Öffnen einer Form (in der IDE) werden ja aus der DFM-Datei die Form und alle Komponenten in diesem Moment "hochgestreamt". Theoretisch müsste es doch möglich sein sich in das Streaming einzuklinken.
So... beim Createprozess einer Komponente wird ja die Procedure DefinePropertys(Filer: TFiler) durchlaufen, hier habe ich die Möglichkeit eigene Proceduren "einzuklinken" wie ReadBinariData(Stream: TStream) und WriteBinäriDate(Stream: TStream), damit hänge ich schon mal dazwischen....

Delphi-Quellcode:

procedure Txxxx.ReadBinaryData(Stream:TStream);
Begin
  ...
End; 

procedure Txxxx.WriteBinaryData(Stream: TStream);
Begin
  ....
End;

procedure Txxxx.DefineProperties(Filer: TFiler);
begin
  inherited DefineProperties(Filer)
  Filer.DefineBinaryProperty('NameProperty',ReadBinaryData,WriteBinaryData,fFlagxx); 
end;

wäre das nicht doch ein Ansatzpunkt ?




Hallo Union

Zitat:

Du könntest versuchen, die Klassen weiter "aufzudröseln". Also eine Basisklasse (TCustomxxx) von der sich dann mehrere Zweige ableiten (TCustomEditablexxx, TCustomNotEditablexxx). Setzt natürlich voraus, dass dies dann auch klar abgrenzbar ist.

Wenn ich die Propertys in der Vorgängerklasse deklariert habe, kann ich die Eigenschaften ja selbst per protected deklarieren und damit verbergen und erst in der abgeleiteten Klasse dann (published) sichtbar machen. Die geht leider nicht, wenn es sich um eine "fremde" Klasse handelt, welche ich nicht verändern kann. Ansonsten finde ich den Vorschlag gut.


Gruß Ulli

[himitsu]

Der andere Weg wäre halt nicht die eigentliche Klasse zu überladen, sondern was eigenes (z.V. von direkt TObject ableiten) nur mit den gewünschten Eigenschaften zu erstellen und dann intern alles auf die andere Klasse umzuleiten.

[guste]

Wenn ich das lese, kommt mir die Direktive reintroduce in den Kopf. Ich weiss jetzt aber nicht mehr ob sich das nur auf Methoden bezog.

[SirThornberry]

Das verbergen ist völlig sinnlos denn man braucht die Klasse nur auf den Vorgänger zu casten (bzw. arbeitet mit dem Vorgänger) und schon kann man auf die properties welche versteckt werden sollten zugreifen.
himitsu hat eigentlich die einzig sinnvolle Variante gepostet.