>Hi Steve,
>Now we mey be getting somewhere.
>I get your vehicle class, but it would still have a BaseClass (probably Custom). What I seem to be getting from the others is that the vehicle class should be based on a "concrete" class mySubCustom that's based on an "abstract" class myCustom that's based on Custom. I should not base vehicle on MyCustom (because it's abstract) but instead base it on mySubCustom. WHY?

PMFJI - normally you don't directly inherit from an abstract class because the abstract class doesn't include all of the code necessary to produce a fully functioning class. It's a design choice. The idea is that it includes all the stuff common to most subclasses you will create (or, in a lot of cases, contain no code at all - they just define the interface via properties, methods and events), but that those subclasses will contain more implementation code to do the real work. While it's also possible to just use this subclass directly, the basic design idea is that you probably will need to customize this class even more for a specific case/form/etc. (eg. set some properties to define behavior, appearance, etc.). In order to maximize reuse, you inherit from the "mySubCustom".

Here's what the hierarchy ends up looking like:

abstract vehicle
^--SpecificVehicle
^--InstanceVehicle

Hope that helped and didn't muddy the waters even more.