Hide unwanted properties.

[Ray Cassick \(Home\)]

Ok, I have finally decided that there is ONE big thing about VB.NET (not
sure if this same thing exists in C# yet) that really ticks me off. Either I
am missing the point here or I have not found what I need to accomplish my
need.

I am creating a Windows forms user control and am inheriting from
System.Windows.Forms.UserControl. There are several properties that are part
of the Usercontrol class that I do not want to expose so I am trying to hide
them as shown below:

<Browsable(False), EditorBrowsable(EditorBrowsableState.Never)> Public
Overrides Property ContextMenu() As System.Windows.Forms.ContextMenu
Get

End Get
Set(ByVal Value As System.Windows.Forms.ContextMenu)
End Set

End Property

But when I place the control on a form and look the properties I have tried
to hide are still present through IntelliSense. Is this not what the
EditorBrowsable attribute is supposed to stop?

--
Raymond R Cassick
CEO / CSA
Enterprocity Inc.
www.enterprocity.com
3380 Sheridan Drive, #143
Amherst, NY 14227
V: 716-316-7537
Blog: http://spaces.msn.com/members/rcassick/

 

[Crouchie1998]

Browsable(False) _
Public Property Bla Bla Bla() As Bla
....
End Property

This will only remove the property from the properties dialog, but not if
you try to accress them in code

Crouchie1998
BA (HONS) MCP MCSE

 

[Ray Cassick \(Home\)]

Yeah, I know that... I can't believe that there is no way to hide this from
code though. It looks like the only thing I can do it thrown an exception if
one of my users tries to use a property that I have not implemented.

Seems mighty messy to me.

I have read a few theories that say hiding inherited properties made
available form a base class is 'bad OO' but I don't think it is. What about
polymorphisam? There are some things I want my control to do differently.
I want to have full control over what MY usercontrol exposes to MY user. I
don't want to have to implement a bunch of properties I don't care about
just because of the base class I chose to use.

UGH!

I don't want users to be bale to change my background picture so why should
I have that available on my list of properties? More so, if it is available
why would it throw an exception when someone tries to use it?

Just seems VERY messy tome.

 

[Michael C#]

Just a thought, but what if you override the property but make it's scope
Private? Not even sure if this is possible, but it might be worth
checking... Alternatively, instead of throwing an exception, you could make
the property do nothing at all if a user tries to assign a value to it -
just make sure you document that the property has no effect...

Just a couple things to try. Good luck.

 

[Adam Goossens]

Unfortunately, as handy as that would be sometimes, you can't do it. If
you override a member it must have the same scope as it's base -
otherwise you would totally break polymorphism.

I agree with your second point though: I think the best idea would be
the override the property to ensure it has no effect when called by the
user. Don't worry about throwing exceptions, it's probably not worth the
effort (although you can if you really want to). Your users will quickly
find out the property is useless when it doesn't do anything

Also as Michael mentioned: make sure you document it.

Regards,
-Adam.

 

[Ray Cassick \(Home\)]

If you make them Private Shadows they still seem to show up in the IDE.

If you make them Private Overrides you get an error saying that you can't do
that because the base class has a different access level (public).

Nice try though I have been at it all night trying to come up with a way
and I have come to the conclusion that there is no way right now.

I weighed the cost (user experience) regarding throwing an exception vs.
just not dealing with them and I think the latter is way more confusing. To
be bale to assign data through a property and simply have nothing happen
looks to the user more like a bug, even if it is documented that the
property is not implemented. Do users ever read the docs?

Perhaps if I created a category of 'Not Implemented and put them all under
there....

Isn't there some attribute that allows you to mark things as deprecated?
Hmmm Maybe I could just mark them all with the Obsolete attribute...

 

[Cor Ligthert]

Ray,

When you look in the controls, you can see as well some properties which are
in my opinion shadowed. They are there however do nothing.

Just my thought,

Cor

 

[Richard Myers]

Either I am missing the point here or I have not found what I need to

accomplish my need.

I think you are. If you dont want to expose all of the functionality of a
base class then dont inherit from it. Whatever you do your user will still
be able to cast down and access baseclass properties anyway. Look into the
inheritence tree where maybe something deeper down will better suit your
needs.

Richard

 

[Doker]

Isn't there some attribute that allows you to mark things as deprecated?

Hmmm Maybe I could just mark them all with the Obsolete attribute...

and a description attribute saying "Intentionally not implemented"

 

[Ray Cassick]

But then that means that I loose all the implementation that I DO want from
the base

I suppose that I could look into using Panel as a base class and inherit
from there, but really, if any of the controls inherit from
System.Windows.Forms.usercontrol then I end up getting all that baggage.

Sounds like I need to inherit from object and just build my own completely
ownerdrawn control.

Really though, my big beef here is that MS gives us the
EditorBrowsable(EditorBrowsableState.Never) but it apparently does not do
anything. If it does nothing then why have it. It seems like this was the
exact scenario this attribute was designed for.

 

[Ray Cassick]

Yes, I can get it removed form the property box... I want it removed from
the code window as well. I don't want it to show up in IntelleSense.

When someone types:

ControlName.

I don't want it to show up there either. As far as I have been told you
can't block that...

 

[Richard Myers]

Hmm I think Microsoft need to define what they mean by "Editor". I was
thinking it just meant the editors in design view in this sense given the
Intellisense it really just a cut down object inspector, but i can see how
you could interpret as CodeWindow Editor.

Perhaps its just a very poorly named Attribute or maybe you have to apply
the attribute at the inheritence hierarchy level where the property/method
is *first* defined. I.e because you're overridding you wont be able to hide
it through the use of this attribute but if it were a property you defined
that was going to be subclassed then applying this attirbute would hide it
from *future generations*.

Richard

 

[Ray Cassick \(Home\)]

Yeah, the Browseable attribute I get. It hides the property from the
property browser. But that EditorBrowsable just makes no sense to me.