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(Fals e), _
EditorBrowsable (EditorBrowsabl eState.Never), _
RefreshProperti es(RefreshPrope rties.Repaint), _
Description("Ge ts 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 PostFilterPrope rties(ByVal properties As
IDictionary)
properties.Remo ve("Text")
MyBase.PostFilt erProperties(pr operties)
End Sub

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

What's wrong?

Thank you.

Dom

[Michel Posseth [MCP]]

Re: Hiding a Property


You might consider private property`s

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

regards

Michel Posseth



"Dom" <dom.dominiqueR EMOVE@gmail.com schreef in bericht
news:u3HEGcy0GH A.4228@TK2MSFTN GP06.phx.gbl...

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(Fals e), _
EditorBrowsable (EditorBrowsabl eState.Never), _
RefreshProperti es(RefreshPrope rties.Repaint), _
Description("Ge ts 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 PostFilterPrope rties(ByVal properties As
IDictionary)
properties.Remo ve("Text")
MyBase.PostFilt erProperties(pr operties)
End Sub
>
but, again, the Text property is accessible by IntelliSense.
>
What's wrong?
>
Thank you.
>
Dom

[Dom]

Re: Hiding a Property

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

[Dennis]

Re: Hiding a Property

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


"Dom" wrote:

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]

Re: Hiding a Property

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]

Re: Hiding a Property


"Dom" <dom.dominiqueR EMOVE@gmail.com wrote in message
news:%235nBiE20 GHA.4228@TK2MSF TNGP06.phx.gbl. ..

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
>
>

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 NotImplementedE xception
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

[M. Posseth]

Re: Hiding a Property

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







"Dom" wrote:

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]]

Re: Hiding a Property

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

"Dom" <dom.dominiqueR EMOVE@gmail.com schreef in bericht
news:u3HEGcy0GH A.4228@TK2MSFTN GP06.phx.gbl...

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(Fals e), _
EditorBrowsable (EditorBrowsabl eState.Never), _
RefreshProperti es(RefreshPrope rties.Repaint), _
Description("Ge ts 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 PostFilterPrope rties(ByVal properties As
IDictionary)
properties.Remo ve("Text")
MyBase.PostFilt erProperties(pr operties)
End Sub
>
but, again, the Text property is accessible by IntelliSense.
>
What's wrong?
>
Thank you.
>
Dom

[Dennis]

Re: Hiding a Property

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


"Mythran" wrote:

>
"Dom" <dom.dominiqueR EMOVE@gmail.com wrote in message
news:%235nBiE20 GHA.4228@TK2MSF TNGP06.phx.gbl. ..

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

>
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 NotImplementedE xception
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
>
>
>

[Dom]

Re: Hiding a Property

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
PreFilterProper ties and PostFilterPrope rties?

And, again, what it the pourpose of the statement
EditorBrowsable (EditorBrowsabl eState.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.C ontrol, but not all controls make use of
Text property. Also I have a lot of controls derived from
ContainerContro l, 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.C ontrol.

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 NotImplementedE xception
exception.

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

BTW: I just discovered that using
EditorBrowsable (EditorBrowsabl eState.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 PostFilterPrope rties
method and EditorBrowsable attribute.


Thanks!

Dom

[Dom]

Re: Hiding a Property

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]

Re: Hiding a Property

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
incomprehensibl e 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.C ontrol.
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]]

Re: Hiding a Property

Aha ,,, i understand now :-)

well this might help

you can apply a controldesigner to your usercontrol...

http://msdn.microsoft.com/library/de...classtopic.asp

http://msdn.microsoft.com/library/de...classtopic.asp

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

regards

Michel





"Dom" <dom.dominiqueR EMOVE@gmail.com schreef in bericht
news:%23Rvnq3D1 GHA.328@TK2MSFT NGP06.phx.gbl.. .

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
incomprehensibl e 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.C ontrol.
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

[Dom]

Re: Hiding a Property

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:

Aha ,,, i understand now :-)
>
well this might help
>
you can apply a controldesigner to your usercontrol...
>
http://msdn.microsoft.com/library/de...classtopic.asp
>
http://msdn.microsoft.com/library/de...classtopic.asp
>
I have never used it myself but this seems to do what you want
>
regards
>
Michel
>
>
>
>
>
"Dom" <dom.dominiqueR EMOVE@gmail.com schreef in bericht
news:%23Rvnq3D1 GHA.328@TK2MSFT NGP06.phx.gbl.. .

>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
>incomprehensib le 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

>
>

[Mythran]

Re: Hiding a Property


"Dom" <dom.dominiqueR EMOVE@gmail.com wrote in message
news:%23ockp3D1 GHA.4748@TK2MSF TNGP04.phx.gbl. ..

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
PreFilterProper ties and PostFilterPrope rties?
>
And, again, what it the pourpose of the statement
EditorBrowsable (EditorBrowsabl eState.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.C ontrol, but not all controls make use of
Text property. Also I have a lot of controls derived from
ContainerContro l, 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
>encapsulatin g 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.C ontrol.
>
>

>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
>NotImplemented Exception exception.

This is a very good approach. But, however, the property/method is still
exposed by IntelliSense.
>
BTW: I just discovered that using
EditorBrowsable (EditorBrowsabl eState.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 PostFilterPrope rties
method and EditorBrowsable attribute.
>
>
Thanks!
>
Dom

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

Mythran