Say you have (psuedo code):

DEFINE CLASS Grandpa AS TEXTBOX
PROCEDURE INIT
  = MESSAGEBOX( 'Hi, we're in the myTextBox object init' )
END PROCEDURE
ENDDEFINE

DEFINE CLASS Dad AS TEXTBOX
ENDDEFINE

DEFINE CLASS daughter AS TEXTBOX
ENDDEFINE

It is my understanding that the Grandpa object's init() *should* fire for the Daughter object since there is no code in it or its parent's method. Only if there is code in the daughter do you need a DODEFAULT in *her* init.

As for the DOFAULT weirdness, I *think* I remember from a long and very interesting discussion somebody had with David Frankenbach, that if you have code in Daughter, and a DODEFAULT() in daughter and
HTH

>>> I instantiate a form off the local layer, and guess what - it runs the .init of the eldest class in the hieararchy. I'd have to stuff lots of dodefault()s upstream to make it behave.
>>
>>That's the way it's supposed to work. Do you mean it's not running the init of the grandparent class?
>
>No, it runs the grand-grandparent's init, when the class and parentclass inits are empty. Accordingly it skips the code for some commandbuttons (which don't exist in the grand-grandparent class) etc. As soon as there's something in tha parent class code, it works. I remember there was something about the dodefault() bug in 5.0, but this seems to (not) work contrary to that. I'll leti it simmer for a while until someone comes up with a solution (or I dig down deep enough).