Hiding a Property

[Dom]

Hi all
I'm developing a control, and I need to hide some properties to the
user. For example, suppose I need Text property to be completely
inacessible (from a Form/Code that is into another project/assembly).

I tried with attributes:

<Browsable(False), _
EditorBrowsable(EditorBrowsableState.Never), _
RefreshProperties(RefreshProperties.Repaint), _
Description("Gets or sets the control's Text value.")> _
Public Shadows Property Text() As String
Get
Return MyBase.Text
End Get
Set(ByVal Value As String)
If MyBase.Text <> Value Then
MyBase.Text = Value
End If
End Set
End Property

but I discovered that Text property is invisible by the property
browser, but it is still accessible through IntelliSense.
Then, I tried associating a designer:

Protected Overrides Sub PostFilterProperties(ByVal properties As
IDictionary)
properties.Remove("Text")
MyBase.PostFilterProperties(properties)
End Sub

but, again, the Text property is accessible by IntelliSense.

What's wrong?

Thank you.

Dom

 

[Michel Posseth [MCP]]

You might consider private property`s

you can also choose to declare only the get or set private

regards

Michel Posseth

 

[Dom]

Michel Posseth [MCP] said the following On 08/09/2006 16.07:

You might consider private property`s

This does not seems to solve my problem: in case of an inherited
property (such as Text) a private property declaration simply make
IntelliSense show the parent property.

you can also choose to declare only the get or set private

Sorry, I don't understand what you mean...

Thank you for reply.
Dom

 

[Guest]

I have the same problem and have not found any solution to force Intell... to
not show it. What I do is shadow the property in my control then if the user
tries to set it, just ignore it or force an error. However, I think the user
can actually set the property in the base control thru reflection.
--
Dennis in Houston

Michel Posseth [MCP] said the following On 08/09/2006 16.07:

You might consider private property`s

This does not seems to solve my problem: in case of an inherited
property (such as Text) a private property declaration simply make
IntelliSense show the parent property.

you can also choose to declare only the get or set private

Sorry, I don't understand what you mean...

Thank you for reply.
Dom

 

[Dom]

Dennis said the following On 08/09/2006 17.56:

I have the same problem and have not found any solution to force Intell... to
not show it. What I do is shadow the property in my control then if the user
tries to set it, just ignore it or force an error. However, I think the user
can actually set the property in the base control thru reflection.

With this approach the first problem is that an exception can be raised
at run-time only, not at design time, and the property remains accesible
like others.
What I need is make a property invisible, not just unusable.
Today I tried to convert my project to VS2005, and I've seen that
IntelliSense DOES NOT expose the property despite it remains usable.
Maybe the problem is a bug of VS2003?


Anybody have any solution for hiding an inherited property/member?

Thanks!

Dom

 

[Mythran]

Dennis said the following On 08/09/2006 17.56:

With this approach the first problem is that an exception can be raised at
run-time only, not at design time, and the property remains accesible like
others.
What I need is make a property invisible, not just unusable.
Today I tried to convert my project to VS2005, and I've seen that
IntelliSense DOES NOT expose the property despite it remains usable. Maybe
the problem is a bug of VS2003?


Anybody have any solution for hiding an inherited property/member?

Thanks!

Dom

Because of the OOP principles, you cannot "hide" a property. If you inherit
from an object that has a "Text" property, the derived class will contain a
Text property. Even if you could hide the "Text" property, all the
developer would have to do is cast the derived instance into the base class
instance and access the Text property from there.

There are alternatives to what you are trying to achieve though. One is
encapsulating the base object completely within the derived class. Instead
of inheriting the base class, you create an instance of the class and store
the reference in a member variable inside the class you are creating. Any
properties/methods you would like to expose of the private instance you
would expose via properties/methods of your class. This can be a pain for
large classes where you would like to expose large numbers of
properties/methods, but it works most of the time. And lastly, the last
alternative would be to inherit from the class, override the property you
don't want the developers to use, and throw an NotImplementedException
exception. This way, if the developer does access it, at runtime an
exception that specifically states what the problem is, is thrown. This is
actually really simple to do. If the developer casts to base class and
accesses the property, the exception is still thrown.

Oh, for shadowing methods. If you shadow a method and changes it's accessor
to not be visible (private, friend) then when the classes property is called
at runtime, the shadowed property/method is not called. Instead, the base
classes property/method is ... I believe ... correct me if I'm wrong...but I
believe that's the way it is.

HTH,
Mythran

 

[Guest]

Well maybe i understood you wrong

i understood that you have a property that you do not want to be accessible
outside your assembly .

well you can do this through the scope qualifiers in VS.net 2005 you can
even mix the get and set qualifiers ( Private , Friend , Public differ for
get and set )


Now i understand that you want your property to be fully functional to the
outside world however you do not want to show that it is actually there .

well i do not believe this confirms to OOP ,,, if i may ask why do you want
this behavior ?

regards

Michel

Michel Posseth [MCP] said the following On 08/09/2006 16.07:

You might consider private property`s

This does not seems to solve my problem: in case of an inherited
property (such as Text) a private property declaration simply make
IntelliSense show the parent property.

you can also choose to declare only the get or set private

Sorry, I don't understand what you mean...

Thank you for reply.
Dom

 

[Cor Ligthert [MVP]]

Dom,

In my opinion you cannot. The same is with the background from the
picturebox. It is there but does nothing, Herfried does not agreed this with
me, he can be right, but I never saw a working sample from him about this.

Cor

 

[Guest]

Can you override any properties or only certain ones. What about inherited
methods...how do you hide them?

 

[Dom]

Hi Cor

Cor Ligthert [MVP] said the following On 09/09/2006 14.51:

Dom,
In my opinion you cannot. The same is with the background from the
picturebox. It is there but does nothing,

This is a core statement! "It is there but does nothing". This can be
good, but it exclude a 'private' use of a property. Furthermore, for a
user is not acceptable that you offer a property that "does nothing".
Thank you!
Dom

 

[Dom]

Hello Mythran,

Because of the OOP principles, you cannot "hide" a property.

If this is true, and I cannot doubt is it, what is the pourpose of
PreFilterProperties and PostFilterProperties?

And, again, what it the pourpose of the statement
EditorBrowsable(EditorBrowsableState.Never)??

I understand that hiding a property/method does actually not hides the
same base property/method, but I think is not difficult a case (like
mine) where some properties are really useless.
In my case, I have lot of controls derived from
Windows.System.Windows.Forms.Control, but not all controls make use of
Text property. Also I have a lot of controls derived from
ContainerControl, but my controls are not designed to be scrollable, and
this is why I need to hide "AutoScroll" property.

There are alternatives to what you are trying to achieve though. One is
encapsulating the base object completely within the derived class. Instead
of inheriting the base class, you create an instance of the class and store
the reference in a member variable inside the class you are creating.

You are right. This is an approach I actually use for some of my custom
classes. But I cannot use this method when i derive from a class like
Windows.System.Windows.Forms.Control.

And lastly, the last
alternative would be to inherit from the class, override the property you
don't want the developers to use, and throw an NotImplementedException
exception.

This is a very good approach. But, however, the property/method is still
exposed by IntelliSense.

BTW: I just discovered that using
EditorBrowsable(EditorBrowsableState.Never)
make a property is STILL visible in VS2003, but correctly NOT visible
with VS2005 (same project).

Oh, for shadowing methods. If you shadow a method and changes it's accessor
to not be visible (private, friend) then when the classes property is called
at runtime, the shadowed property/method is not called. Instead, the base
classes property/method is ... I believe ... correct me if I'm wrong...but I
believe that's the way it is.

You are absolutely right: the parent propery/method is colled instead.


Thank you for your comments!

I should greately appreciate your comment about PostFilterProperties
method and EditorBrowsable attribute.


Thanks!

Dom

 

[Dom]

Hi Michel

M. Posseth said the following On 09/09/2006 13.14:

well you can do this through the scope qualifiers in VS.net 2005 you can
even mix the get and set qualifiers ( Private , Friend , Public differ for
get and set )

This feature is not availabe to VS2003. This is why your suggestions was
incomprehensible for me!

well i do not believe this confirms to OOP ,,, if i may ask why do you want
this behavior ?

Currently, I have a lot of controls derived from
Windows.System.Windows.Forms.Control.
As you can easily fugure, not all controls make use of Text property,
for example. In other controls, I make a 'private' use of Text property.
This is why I need hide some properties.

Thank you for your help.
Dom

 

[Michel Posseth [MCP]]

Aha ,,, i understand now

well this might help

you can apply a controldesigner to your usercontrol...

http://msdn.microsoft.com/library/d...ndowsformsdesigncontroldesignerclasstopic.asp

http://msdn.microsoft.com/library/d...onentmodeldesignidesignerfilterclasstopic.asp

I have never used it myself but this seems to do what you want

regards

Michel

 

[Dom]

Hi Michel
as I reported in my first post, I already implemented a Control
Designer, but it did not worked.
Thank you for the hint, I'll try again
Dom



Michel Posseth [MCP] said the following On 10/09/2006 12.34:

 

[Mythran]

Hello Mythran,

If this is true, and I cannot doubt is it, what is the pourpose of
PreFilterProperties and PostFilterProperties?

And, again, what it the pourpose of the statement
EditorBrowsable(EditorBrowsableState.Never)??

I understand that hiding a property/method does actually not hides the
same base property/method, but I think is not difficult a case (like mine)
where some properties are really useless.
In my case, I have lot of controls derived from
Windows.System.Windows.Forms.Control, but not all controls make use of
Text property. Also I have a lot of controls derived from
ContainerControl, but my controls are not designed to be scrollable, and
this is why I need to hide "AutoScroll" property.


You are right. This is an approach I actually use for some of my custom
classes. But I cannot use this method when i derive from a class like
Windows.System.Windows.Forms.Control.


This is a very good approach. But, however, the property/method is still
exposed by IntelliSense.

BTW: I just discovered that using
EditorBrowsable(EditorBrowsableState.Never)
make a property is STILL visible in VS2003, but correctly NOT visible with
VS2005 (same project).

You are absolutely right: the parent propery/method is colled instead.


Thank you for your comments!

I should greately appreciate your comment about PostFilterProperties
method and EditorBrowsable attribute.


Thanks!

Dom

From what I read in MSDN, the PostFilterProperties just allows you to filter
(add/remove) properties visible from the TypeDescriptor. Doesn't actually
change the properties of the object....

Mythran