>>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 can imagine that at least one child from a base class is 'necessary' or at least useful. But if that child contains ALL that you need in a part of the application (apart from what must be set in the instance itself) then why declare it abstract?
>

i.e. before VFP had the anchor-property we had created this property within out framework by default. With VFP introduction to this, we ran into an error as there was already a property called 'anchor' within VFPs baseclass.
So all we had to do, was renaming our property and changing the corresponding code snipets.

>>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...
>
>What was the reasoning for such an 'empty' class?

I really don't know anymore. As far as I remember this was in 2002. And as already mentioned, I didn't use this approach.