|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Hide unwanted properties.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/ 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 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. Show quoteHide quote "Crouchie1998" <crouchie1998@spamcop.net> wrote in message news:uoSlb5iPFHA.1392@TK2MSFTNGP10.phx.gbl... > 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 > > 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. Show quoteHide quote "Ray Cassick (Home)" <rcassickNOSPAM@enterprocity.com> wrote in message news:eVlTJFjPFHA.3356@TK2MSFTNGP12.phx.gbl... > 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. 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. Michael C# wrote: Show quoteHide quote > 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. > 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... Show quoteHide quote "Michael C#" <x**@abcdef.com> wrote in message news:W8m6e.3009$3g7.92@fe11.lga... > 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. > > "Ray Cassick (Home)" <rcassickNOSPAM@enterprocity.com> wrote in message > news:eVlTJFjPFHA.3356@TK2MSFTNGP12.phx.gbl... >> 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. > > 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 > Isn't there some attribute that allows you to mark things as deprecated? and a description attribute saying "Intentionally not implemented"> Hmmm Maybe I could just mark them all with the Obsolete attribute... > 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 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. Show quoteHide quote "Richard Myers" <f***@address.com> wrote in message news:%23bTZZumPFHA.1268@TK2MSFTNGP14.phx.gbl... > > > 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 > > O.k well ive tried to replicate your query and context menu example you
described and for me it works. Context Menu is NOT available via the forms property box. Richard Show quoteHide quote "Ray Cassick" <rcassick@nospam.enterprocity.com> wrote in message news:exlBjGtPFHA.2680@TK2MSFTNGP09.phx.gbl... > 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. > > > > "Richard Myers" <f***@address.com> wrote in message > news:%23bTZZumPFHA.1268@TK2MSFTNGP14.phx.gbl... > > > > > 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 > > > > > > 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... Show quoteHide quote "Richard Myers" <f***@address.com> wrote in message news:uzluu9yPFHA.3076@tk2msftngp13.phx.gbl... > O.k well ive tried to replicate your query and context menu example you > described and for me it works. > Context Menu is NOT available via the forms property box. > > Richard > > "Ray Cassick" <rcassick@nospam.enterprocity.com> wrote in message > news:exlBjGtPFHA.2680@TK2MSFTNGP09.phx.gbl... > > 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. > > > > > > > > "Richard Myers" <f***@address.com> wrote in message > > news:%23bTZZumPFHA.1268@TK2MSFTNGP14.phx.gbl... > > > > > > > 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 > > > > > > > > > > > > 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 Show quoteHide quote "Ray Cassick" <rcassick@nospam.enterprocity.com> wrote in message news:ePPFJ$3PFHA.3196@TK2MSFTNGP12.phx.gbl... > 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" <f***@address.com> wrote in message > news:uzluu9yPFHA.3076@tk2msftngp13.phx.gbl... > > O.k well ive tried to replicate your query and context menu example you > > described and for me it works. > > Context Menu is NOT available via the forms property box. > > > > Richard > > > > "Ray Cassick" <rcassick@nospam.enterprocity.com> wrote in message > > news:exlBjGtPFHA.2680@TK2MSFTNGP09.phx.gbl... > > > 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. > > > > > > > > > > > > "Richard Myers" <f***@address.com> wrote in message > > > news:%23bTZZumPFHA.1268@TK2MSFTNGP14.phx.gbl... > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > Yeah, the Browseable attribute I get. It hides the property from the
property browser. But that EditorBrowsable just makes no sense to me. Show quoteHide quote "Richard Myers" <f***@address.com> wrote in message news:%23tsL598PFHA.1392@TK2MSFTNGP10.phx.gbl... > 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" <rcassick@nospam.enterprocity.com> wrote in message > news:ePPFJ$3PFHA.3196@TK2MSFTNGP12.phx.gbl... >> 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" <f***@address.com> wrote in message >> news:uzluu9yPFHA.3076@tk2msftngp13.phx.gbl... >> > O.k well ive tried to replicate your query and context menu example you >> > described and for me it works. >> > Context Menu is NOT available via the forms property box. >> > >> > Richard >> > >> > "Ray Cassick" <rcassick@nospam.enterprocity.com> wrote in message >> > news:exlBjGtPFHA.2680@TK2MSFTNGP09.phx.gbl... >> > > 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. >> > > >> > > >> > > >> > > "Richard Myers" <f***@address.com> wrote in message >> > > news:%23bTZZumPFHA.1268@TK2MSFTNGP14.phx.gbl... >> > > > >> > > > > 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 >> > > > >> > > > >> > > >> > > >> > >> > >> >> > > 
Other interesting topics
Can't destroy Excel Process; tried Just about everything!
NullReferenceException when setting to array list Visual Basic.net My application exits after handling an ApplicationException How to catch a right-click Error after removing row and then adding new row to datatable Naming convention for objects Re: Freeze Column in DataGrid How to copy files from desktop to web server why does my app.productionversion not auto increment? |
|||||||||||||||||||||||
