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


I like the "Scream and shout" comment <g>. I bet it was even more vivid in German....