Hi Peter,

abstract classes are necessary to define the pure interface for your concrete classes. This way you can react to language- and property modifications. From VFP9 point of view this might not be necessary anymore, as there won't be any changes coming by MS, but for me that's no reason to change my behaviour.

I remember someone said ( at DEVCON in Frankfurt) that you should use a unchanged inherited class i.e _textbox and a second class atextbox inherited from _textbox which defines additional properties and methods. But I have to admit, that I didn't like the work behind this, as I would have had to reconstruct too many classes...

>This week I noticed I was using abstract classes as concrete classes. Trying to reconstruct things I again started to doubt the usefulness of having abstract classes.
>
>Some history: I'm probably the only developer in the whole world who's actually using this great tool NewClass.app - written by myself and available to all at http://www.viafox.nl/downloads/NewClass_beta2.zip - and thereby giving structure to the names of his new classes. It is a wizardlike tool and one of the first choices to be made is whether the new class will be abstract or concrete. After a while I noticed that I had been using abstract classes in my form, notwithstanding the fact that they can be easilly recognized by the underscore at the end of their name. However, the form works perfect.
>
>The crucial issue is that there is probably no gain in having a concrete class that's totally equal to the abstract class that it is based on. On the contrary, there is likely a loss, for example because it gives useless overhead in loading.
>
>What's your opinion here?