>>>Save() was merely used by me as an example of Method Overloading. Some developers add certain methods and properties to all their classes as part of their homemade (attempt for a) framework.
>>
>>understood.
>>
>>Not considering how and where you would implement save() still such a button would get concrete as soon as the form it's on is a concrete form. And if there is no code or anything added or implemented in that button on that way of subclassing, it's nevertheless a concrete button. If there would need to be somthing implemented which, when missing will cause errors, it will cause errors, then it's an error of usage. But it's not an error of the class to instanciate then.
>
>If my idea is correct that a class is abstract as long as it is incomplete, even if it is concrete in the eye of the developer (or for example, if it is on a form), then an abstract class on another class has not necessarilly become concrete. Even a form (an .scx) is then abstract as long as it still misses crucial information.

I'd just call that wrong usage.

And if that form would still be abstract and you implement that mechanism throughout all abstract classes, the button would instanciate but the form won't. So it won't matter that the button behaves as a concrete button, because the form bahaving as an abstract form is sufficient, so the whole thing won' run.

You might consider returning .f. from form.load in abstract forms, so it's abstract or concrete controls won't even init().

Bye, Olaf.