>>Bonnie, does this kind of inheritance model (exception) make sense to you? And if it does, why? I don't personally see what the reason might possibly be, but then again, what do I know.
>>
>>Maybe I'm missing something (big) here, but I can't see why the HECK I can't simply and codelessly overwrite parent class' properties like ReadOnly and Enabled and Font in a child class. It is sooooo counterintuitive and annoying to me to have to keep these kinds of exceptions in my already overloaded memory banks. Wasted storage, as far as I'm concerned. Isn't this one of the cornerstones of OOP inheritance: If a PEM is visible and accessible in the parent, it should be always and freely overrideable in the child. Period.
>>
>
>Because the designers of the class decided they didn't want you to be able to do that. If they did, they would have marked it as "virtual". It's consistent OOP, although you might question the logic of the design. When you build classes you can flag the visibility of methods/properties in subclasses (or even if it can be subclassed). You can also set whether a method/prop. can be overridden in subclasses.

Thanks, Paul.

I have to say, I guess I've been relying too much on frameworks and custom controls to do the heavy lifting for me, and hence haven't gotten far enough into .NET inheritance nitty gritty.

Pertti