>>>>>And the product is called Visual Studio and everything is class based - what a joke.
>>>>
>>>>
>>>>The fact that there isn't much visual inheritance in VS does not make it a joke. The visual is the preview that you have in all of your design efforts. I like the fact that everything is class-based.
>>>
>>>Well said. Besides, how often do we subclass GUI components (in any development environment)?
>>
>>Very often if you really follow OOP. In fact you never use a base class if you can help it. You inherit not cut and paste if you want to change/modify functionality.
>
>Thank you for the tutorial but I didn't just fall off the turnip truck, Bernard. I am quite familiar with the principles of OOP. One of the things that might be said about it is that excessive use of inheritance is the sign of a neophyte. (Not directing that at those who posted yesterday in favor of inheriting base classes two levels, one for the company and one for projects within a company; I like that). Done improperly, you can quickly wind up with a maze of classes that aren't a lot more maintainable than "spaghetti code" in the old days.

True. Un necessary subclassing for the sake of subclassing is not what I mean.

One level to build a set of base classes and another for functionality. At the extreme 3 levels though I have only sometimes used that.

For example - 3 levels (my max)

1. Subclass the base classes
2. Add functionality to these after subclassing for use in a particular project
3. Combining from 2 to create a user control only if it will be reused at least once.

For instance in a ERP club management system, level 2 would give say a text control functionality and themes for the project.

For the POS screens the text controls from 2 would be combined as a user control and used in a number of screens across the project giving them all the same look and feel.

After 3 levels it becomes spaghetti and too difficult to maintain.