Thomas,

That's a stab at it, but it'll need more tweaking because the function is depth dependent. At a third level of inheritance it doesn't work:

ox = createobject( "g3b" )
ox.Draw()  && assert not triggered

define class G1b as GraphicAbstractObject
enddefine

define class G2b as G1b
enddefine

define class G3b as G2b
enddefine

If I was to write abstract inheritance enforcement I'd probably to it as a build time tool.

>My example was just typed in, as my missing out returning the method name of the abstract shows <g>.
>Your objection is certainly valid, but something along the lines of

>function AbstractWarn()
>  local lcSetAssert, lcAbsCaller
>  lcAbsCaller = Program(program(-1)-1)
>  if not JustExt(m.lcAbsCaller)==JustExt(Program(program(-1)-2))
>    lcSetAssert = set("Assert")
>    set Assert on
>    assert .f. Message m.lcAbsCaller + " should be overwritten !"
>    set Assert &lcSetAssert
>  endif

>
>should be able to fix it for most usages (Again just typed in not tested ...Update - and on second reading might need some error checking to make sure there *is* a programmatic level -2 /Update). The case of a method *just* calling the dodefault() could be argued to be something for the code police or a valid use case suppressing the assert<g>. For me having explicit abstract levels has no merit *in vfp* unless there is some automatic tool working on extracting documentation on such levels or other on site "programming rules". But now we are deep in "opinion space".