Hi John,

thanks for your thoughs ... my further thoughts in context below:

>>1) If a property is protected, I STILL think I, as the designer, should be able to set it at the instance level IN THE DESIGN ENVIRONMENT. That is, I want to be able to set the property up to some different default for each instance, but still want it to be 'protected' i.e. other objects can't change it. What am I missing here?
>
>I think you're taking the wrong view of it. Protected means just that: Protected. Only accessable from the class and direct subclasses. A Protected property cannot be changed at the instance level and leaving it exposed in the design environment sets up a possibility of changing it in the instance which is a big no-no at anytime. See?

Well - I understand that's how it works and is the 'philosophy' behind, it - I'm just not sure I agree. To me there is a BIG difference between the design environment and runtime. So let me state the problem another way, If I had a class - let's say a button class with a property '.cName', and all the button did was bring up messagebox(this.cname) fom the click event, under the current model, I have no way to drop 6 or 8 of these buttons on a form, set differnt .cNames for them, and yet still have those .cNames inaccessible to outside objects at runtime ... and that doesn't seem right

>>2) Again, with protected, I belive that other objects created at the same class level should be able to access protected properties of an object. For example, if I have a form class - and create some protected property on that class, WHY can't buttons, etc. ALSO added to that class access the property? In my mind - buttons, etc added to a form (or other container class) ought to count as part of that container class as far as protected goes.
>
>Your form class with buttons and whatnot put into the class definition is a composite class. Other members of the composite have their own heirarchy and are, therefore, not subclasses of the form where the Protected property is.

Ah - but to me - the whole composite class IS one class, despite the fact that the components have their own class heirarchy. In this scenario, I believe a buttons method has as much right to get to a form's protected property as any of the form's methods do ... and often times, as much need.

>If you have these needs, then perhaps you don't really want to use Protected or Hidden properties.

Well - only if there were a third 'property concealment state' that functioned like I want. To me - protected means 'protected from the outside' not 'protected from myself'

Thanks!
Ken