>I've rather changed my mind during our discussion to not allow such classes that get concrete at runtime. Now I am a bit undecided again.
>
>You introduce a possibility to override IamConcrete() simply with RETURN .T., my proposed init() method can be overridden too, but you seldom use a class overriding it's init behaviour. And once you set the classname you can't change it.
>
>Concrete or abstract should be clear beforehand, like a method should not dynamically be public or private...

My point in the java example was that the "abstract" keyword helped (even only in a tiny bit) to compile-check the needed overrides. In vfp you can also gain the same "structural clarity", but the compiler support is missing.

>
>On the other side you wouldn't want to define N concrete buttons, each only differing in the method name set in it's cAbstractFormClickmethod property. In a dynamic language like vfp you would want to have such dynamic behaviour and so it should be allowed. the way out could be you define that dynmic class to be concrete, even though it could stay abstract, if it's not initiated correctly.

I'd probably build a chain of responsibility:

function abstract_click()
  local lcDelegate, llOk, oBehave
  oBehave = thisform.oBehave
  Do Case
     Case Type("this.cFormMethod")="C" and PemStat(m.oBehave, this.cFormMethod, 5)
         *-- if you need a special concrete case, overwrite
         lcDelegate = "this.cFormMethod"
     Case PemStat(m.oBehave, this.Name + "_Click", 5)
         *-- works like a charm in instance subclassing if you have meaningful names
         lcDelegate = this.Name + "_Click"
     Case PemStat(m.oBehave, this.Class + "_Click", 5)
         *-- good default, if it is there
         lcDelegate = this.Class + "_Click"
     Case PemStat(m.oBehave, this.ParentClass + "_Click", 5)
         *-- see above
         lcDelegate = this.ParentClass + "_Click"
     Otherwise
         *-- Scream and shout
         Asse .f. ...
         lcDelegate = ...
  endCase
  llOk = Eval ("oBehave." + m.lcDelegate + "()")
  return m.llOk

allowing me to get by with a minimum of special settings. It allows for concrete "Save" Buttons or a hook up via the objects name, which should be set to something sensible for debugging IAC while I still have the explicit "override" via property.

For integrating with abstract classes not instantiating just add another property "cRealFormMethod", set this according to the chain-case and test viw IamConcrete in the .Init.

regards

thomas