| 

.NET C# Java Javascript Exception

3
Ich möchte in einem selbst programmierten Steuerelement diverse Eigenschaften verbergen, die durch Vererbung übernommen wurden, in meinem abgeleiteten Steuerelement aber nicht benötigt werden. Gibt es hierfür eine Möglichkeit?
News:
07.02.2011
DREAMER 31 1 2
6 Antworten
3
Mit diesem Code, kannst du deine Eigenschaft verstecken.
[Browsable(false)]
public int MyProperty {
get {
// Insert code here.
return 0;
}
set {
// Insert code here.
}
}


via http://msdn.microsoft.com/en-us/library/system.componentmodel.browsableattribute.aspx
07.02.2011
Konstantin 3,7k 8
3
Die Variante mit BrowsableAttribute versteckt die Eigenschaft nur für den Designer (PropertyGrid), die Eigenschaft selbst bleibt natürlich Bestandteil der Klasse und kann nach Instantiierung weiterhin verwendet werden, schließlich wurde sie in der Basisklasse als öffentlich deklariert.
07.02.2011
Norbert Eder 383 4
Das heißt, dass es keine Möglichkeit gibt, eine öffentliche Eigenschaft in einer abgeleiteten Klasse wieder zu verstecken?
Kreta 07.02.2011
Nein. Öffentlich bleibt öffentlich.
Norbert Eder 07.02.2011
2
mit dem Attribut EditorBrowsable(EditorBrowsableState.Never) kann ein Member noch vor der IntelliSense-Auswahl verborgen werden...
10.02.2011
traudi 231 5
0
Die ganzen Vorschläge mit BrowsableAttribute, ObsoleteAttribute und EditorBrowsableAttribute versuchen nur ein Problem zu lösen, das du bei einer ordentlichen Vererbungshierarchie gar nicht hättest.

Jetzt weiß ich zwar nicht, welche Elemente du genau einsetzt, aber wie sieht es denn damit aus, dass dein Steuerelement nicht von einem anderen ableitet, sondern nur als Wrapper fungiert? Damit hättest du es selbst in der Hand, was du nach außen gibst, müsstest dich allerdings um ein paar andere Dinge selbst kümmern.
10.02.2011
Norbert Eder 383 4
Prinzipiell gebe ich dir recht.

Und jetzt kommt das Aber: Wenn das Control von dem abgeleitet wird nicht selbst entwickelt wurde, kann ich den Wunsch schon nachvollziehen. Eine Number TextBox ohne Passwort-Eigenschaft z. B. Da wäre es dann auch mit dem Wrapper ziemlich mühsam.
Maria Simlinger 10.02.2011
Den Wunsch kann ich auch nachvollziehen, deshalb auch ein weiterer Vorschlag, wie er seinen Wunsch realisieren kann.

Zu deinem Beispiel: Der Implementierer muss schon mitdenken auch ;-)
Norbert Eder 12.02.2011
Up-vote weil ich diesen Vorschlag oben im Nachhinein auch gemacht habe ;-)
Torsten Weber 16.02.2011
0
Oops: Dieser Text entstand bevor ich den Beitrag von Norbert Eder gesehen habe.

Das einzige was mir noch einfallen würde, wäre keine Ableitung sondern eine vollständige Kapselung. Du müsstest also die Schnittstelle des Basis-Controls auslesen und sozusagen einen Wrapper implementieren und alle Aufrufe an das Basis-Control weitergeben. Die Eigenschaften/Methoden die nicht mehr erreichbar sein sollen, implementierst Du eben nicht Deinem Control.

Der Aufwand scheint mir allerdings sehr groß und wenn das Basis-Control mal aktualisiert wird fängst Du möglicherweise von vorn an.
16.02.2011
Torsten Weber 691 1 8
-1
Mal abgesehen davon, dass eine abgeleitete Klasse nie ererbte Methoden verstecken sollte, wie sieht es damit aus:

[Browsable("false")]
[Obsolete("This property is obsolete with release x.x.", true)]
public new int MyProperty
{
get { throw new NotImplementedException("obsolete"); }
set { throw new NotImplementedException("obsolete"); }
}


Dann meckert nämlich auch der Compiler ;)
10.02.2011
Maria Simlinger 1,1k 1 9
Kannst du mit einem Up-Cast umgehen.
Norbert Eder 12.02.2011
1
Warum wird diese Antwort von Maria hier "down-gevotet"?
In Ihrem Beispiel ist auf den ersten Blick alles nur erdenklich Mögliche drin, was man tun könnte um den Aufruf zu verhindern. Klar kann man es mit einem Up-Cast umgehen allerdings grenzt das ja schon an Gewalt.
Torsten Weber 15.02.2011
Danke Torsten.
Maria Simlinger 16.02.2011

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH