Hi Dragan

>>>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.

I meant the cosmetic part was just to have a visual effect. What about functionality? If there is a functional change made to frmApplicationSpecficSuperForm I'd have to make that to frmCountry too.

>
>Not necessarily. I've tried the other day, just for fun, a simple decorator objects that recurses through the form's objects and sets the fontname of any object that has the property (just had enough of Arial everywhere :). The decorator is about six lines of .prg (it relies on each form already having a thisform.oRecurser object :), and commits harakiri when done. It took just three lines to instantiate it, run it and then kill it in the end of form's .init... which, in your case, could simply be done at the frmSuperForm level: have a property called DecoratorClass, and then sometime when the coffee is getting cold in .init
>

if not empty(this.DecoratorClass)
>oDecorator=createobject(this.DecoratorClass)
>oDecorator.Upholster(this)
>release oDecorator

>OK, you may need DecoratorClassLib if you want newobject() instead of createobject(), but that's it.