Hallo Freunde,

irgendwie verstehe ich nicht den Hintergund in abgeleiteten Komponenten warum folgendes gemacht wird.

markieren

Code:

type

TIrgendEinEdit = class(TEinEdit) // kein TCustomEdit
published
    property Anchors;
    property AutoSelect;
    property AutoSize;
    property BiDiMode;
    property CharCase;
    property Color;
    // usw.
end;

TMyIrgendEinEdit = class(TIrgendEinEdit) // kein TCustomEdit
 published
    property Anchors;
    property AutoSelect;
    property AutoSize;
    property BiDiMode;
    property CharCase;
    property Color;
    // usw.
end;

Diese property sind doch eh öffentlich also warum werden sie in der Ableitung erneut published ?

Bei der Vererbung wird deren Sichtbarkeit auf public niedrigt. So werden dann die gewünschten wieder sichtbar gemacht

In der Basisklasse sind diese Property noch versteckt.
Hier wurden sie nun für die Verwendung nach Published verschoben und werden dadurch im OI sichtbar/nutzbar.

Der Grund ist einfach, daß man nun von der Basisklasse etwas ableiten kann und dabei die Kontrolle behält, was man in seiner Komponente anzeigen möchte, denn nachträglich verstecken geht schlecht, wenn etwas schonmal sichtbar war.

[edit]

Zitat:

kein TCustomEdit

hmmm, vielleicht hatte man mal von TCustomEdit abgeleitet?

Zitat von himitsu:

kein TCustomEdit
hmmm, vielleicht hatte man mal von TCustomEdit abgeleitet?

War nur ein Beispiel, von Custom deshalb nicht da die Ableitung bereits Erweiterungen enthält.

In der Basisklasse sind diese Property eben nicht versteckt sondern sind bereits published, deswegen frage ich ja nach dem Sinn.

Zitat von mkinzler:

Bei der Vererbung wird deren Sichtbarkeit auf public niedrigt. So werden dann die gewünschten wieder sichtbar gemacht

Hmm... ist das irgendwo dokumentiert, denn wenn ich von der Basisklasse ableite ohne das ich erneut die Property published deklariere sind diese trotzdem published und weiterhin im OI sichtbar.

Nja, schaden kann es nicht, aber wenn es vorher schon sichtbar war, dann änderst sich ja nichts ... ist dann praktisch umsonst.

Wenn das Licht an ist und ich es nochmal anschalte, dann bleibt es ja an und wird nicht anner.

Zitat von himitsu:

Nja, schaden kann es nicht, aber wenn es vorher schon sichtbar war, dann änderst sich ja nichts ... ist dann praktisch umsonst.

Wenn das Licht an ist und ich es nochmal anschalte, dann bleibt es ja an und wird nicht anner.

Ok, damit hat sich meine Frage also beantwortet. Es ist also Sinnlos, komisch finde ich nur das sich die Programmierer, auch bei kommerziellen Komponenten die Zeit nehmen, diese Sinnlosikeit fortzuführen.

Danke

Zitat von Net7:

...Es ist also Sinnlos, komisch finde ich nur das sich die Programmierer, auch bei kommerziellen Komponenten die Zeit nehmen, diese Sinnlosikeit fortzuführen.

Aus Dokumentationszwecken?

Manchmal ist auch die Reihenfolge der published Properties entscheidend, da dadurch die Reihenfolge des Schreibens in einen Stream (z.B. DFM) und folglich auch das nachfolgende Lesen beeinflusst wird. Manche Properties dürfen erst gelesen werden, wenn andere bereits gesetzt sind. Das kann man damit erreichen.

Zitat von alzaimar:

Zitat von Net7:

...Es ist also Sinnlos, komisch finde ich nur das sich die Programmierer, auch bei kommerziellen Komponenten die Zeit nehmen, diese Sinnlosikeit fortzuführen.

Aus Dokumentationszwecken?

Nun bin ich verwirrt, man schreibt zusätzlich Quelltext um zu dokumentieren ??

Zitat von Uwe Raabe:

Manchmal ist auch die Reihenfolge der published Properties entscheidend, da dadurch die Reihenfolge des Schreibens in einen Stream (z.B. DFM) und folglich auch das nachfolgende Lesen beeinflusst wird. Manche Properties dürfen erst gelesen werden, wenn andere bereits gesetzt sind. Das kann man damit erreichen.

Ja, das macht Sinn.
Diese Möglichkeit habe ich noch garnicht in Betracht gezogen, folglich sollte man bei neuen Propertys beachten, ob man Daten von geerbten Propertys benötigt und die "published property" neu ordnen sollte.

Verstehe ich das richtig ?