On my way home I had some more thoughts on this special case:

It's quite normal to define such abstract buttons like a "savebutton_", put them on an abstract form like an "editform_" and then have that "savebutton_" instanciated in a concrete edit form.

It may even be okay that this buton stays as it is, eg it calls thisform.save() and you will implement the concrete save in the concrete editform. So the concrete button does not need to be modified from the abstract button. What makes it concrete is, it's on a concrete form.

So it's the outmost class that defines if the whole class is abstract or concrete, no more, no less.

To use my mechanism of instanciation prevention you would just need to modify it like this:

Return NOT(Right(This.Class,1)=="_") OR Vartype(THIS.Parent)="O"

In fact you would need to check if the outmost parent is concrete or not to decide if this button should be instanciated. But if the outmost parent does run the same init() code and is an abstract class it does not matter that the button is instanciated, the whole form won't be instanciated. Therefore it's sufficient to test if the button is either not abstract or part of some other class.

If you want to be serious, you'd make one concrete subclass from the "savebutton_" called "savebutton" and only use that on forms, as putting it on a form is like instanciating it and that would not be allowed for an abstract class. With foxpro you don't need that, because adding a class to some other in the class designer is not equal to instanciation, it would only bite at runtime, therfore you can but perhaps should not, if you're serious. But you won't win anything in foxpro. You defined the seperate class "savebutton_" and if there is a need for a change of all concrete save buttons you can change that class, there is no need for a second level of a concrete button, except you would want to add such buttons at runtime.

Bye, Olaf.