>If that assumption is correct, then I also assume that it is a valid usage of an abstract class if it is DIRECTLY used in a form and if the Save() method is filled at that level!

That's a good point, writing code in such a controls methods is like defining a last subclass level, that makes it concrete. well you've got your concrete save button, if the abstract is simply having this.save() in this.click() and you implement the save on the form level. But I think it's a better best practice to implement that save() on the class level, that is in a method of the form, not the button. It's not the button, that is saved, it's data displayed on the form, it has to do with the whole form, not with the button.

If you define new methods in the form or a class designer with a form class opened, you only can add methods and properties at the form level. And that is good that way, as that is the level you design now.

It would be hard to make use of my idea to prevent abstract class instanciation, if you allow that usage of the abstract class. You can't make a simple check from the init, if a condition is fullfilled, that makes that abstract save button a concrete save button, as ReadMethod("save") won't work at runtime.

So why not keep the rule simple and even if your abstract save button is just calling thisform.save() and that is sufficient for all the forms in your app, don't accept that button as a concrete button.

Another idea might be, you allow the usage of that abstract button on an abstract form (editform_), an abstract form class for editing any data which for example has a save button on it. Then you could change the instanciation prevention to also accept instanciation, if this.parent.class is no abstract class.

Bye, Olaf.