>Data drive the cosmetic features or have custom properties that you can change that then get read at Init to change the form.

The cosmetic aspect was a simple example. Are you suggesting a decorator class that acts on frmApplicationSpecificSuperForm to make a frmCountryForm? That would require a factory to create frmCountryForm, created by an abstract factory.

>
>
>>Hi all
>>
>>I have a form class that is quite feature-rich. Call it frmSuperForm. I want to use this class for most forms in my new system.
>>
>>I subclass frmSuperForm to frmApplicationSpecifcSuperForm and use it for new forms in the application. All forms have the same look and feel and feature set. Wonderful!
>>
>>I want a frmCountryForm for data entry and selection of countries. frmCountryForm is derived from the original frmSuperForm. However as per the late, great Drew Speedie article about the dangers of composite development, frmApplicationSpecificSuperForm is not in the country form's geneology. They are siblings with a common parent, frmSuperForm. If I subclass frmCountry, I will have to make cosmetic changes to make it look like the frmApplicationSpecificForm. This I wish to avoid.
>>
>>So the question is, how do I create a frmApplicationSpecificCountryForm based on frmApplicationSpecificSuperForm? Creating one from scratch for each new application is stupid. Subclassing frmCountryForm and cosmeticly altering it is a duplicate effort, since I've already cosmetically altered frmApplicationSpecificSuperForm.
>>
>>Thanks