>>One other question on sub-classing:
>>If you have a sub-class that modifies a property from the default value of the baseclass, and then later that property is removed from the baseclass, that property no longer exists in the sub-class. You don't get any error or any indication that the property no longer exists in the base class, until you try to reference it in code for your sub-class. I would have thought that the sub-class property would have just become a new property belonging only to the sub-class. Is this correct functionality?
>
>
>Fred,
>
>That is perfectly correct behavior. If the property is inherited fromt eh parentclass and you later remove it form the parent class, then it is no longer inherited and it does not show in the subclass. You would need to visit the subclass and add that property.
>
>Having a property or method that is not in the parent class can be indicative of a poor class design. The purpose of the highest class level is to define the public interface for all of its subclasses. Introducing a new property or method down the inheritence tree causes the interface to change within the particular class.

Thanks for the clarification, Jim. This hasn't actually happened yet, I was just experimenting with what would if this occurred. I like to be aware of how the symptoms may present themselves BEFORE they actually happen. That way I may be better prepared on how to correct a problem.
I'm not sure I agree with your statement of "poor class design", though. I thought it would be proper to add a new property/method at a subclass level so as not to affect the baseclasses, and not turn them into such a generic mess of trying to be all things to all people? As far as removing properties from a baseclass, I can see how that could be problematic to the sub-classes, though. Our baseclasses have "evolved" over time, and there are several things that need to be removed completely. This should be done before we release our public interface, though.