Hi Olaf,

>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.

For me that is wrong. As soon as the class is put onto a form (or any other container) you have an instance of the .class right on your new composite class/form.

You loose the ability to subclass / override the specific class, you must override in the container context - "proof" is for instance the name mangling schema.

>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"
>

And what about Add Object or .AddObject() vs .CreateObject() ? You specify the *class* in the second parameter of addobject and the rule says: abstact classes won't get instantiated. The "containership" issue, as nice as it is sometimes to have (to go against other OOP rules as in this.parent.oBehave) is just syntactic sugar defining a standardized schema for instantiation and release and a double link in the object hierarchy (.parent and parent.[specificcollection])

As we are touching meaning and semantics, let's lure Dragan into this: "you are on the woodway"

regards

thomas