Yves,
This is a good cause of C05 errors you've isolated here. Thanks
Your lowest level classes never need to issue a call to the VFP BaseClass methods because those are called automatically at the end of all overridden code. The only place you need DoDefault or ParentClass::Method() calls are in the 2nd through Nth levels of class inheritance.
There is a bug in VFP5 (I've not yet tested it in VFP6) where a DoDefault() call from a class to an empty ParentClass method will cause the BaseClass behavior to execute twice. Sometimes this is insignificant, other times like in KeyPress it causes problems. The problem does not occur if you use ParentClass::Method() instead of DoDefault(). There's more detail on my website in the article on the Quicken txtDate class.
>I just picked one thread to be able to inform as many people as possible about my findings.
>
>Following a bit the C000005 error story around on this form.
>I've been enhancing my own framework with in my head the idea to let it inherit from another layer.!?
>What I always did was a DODEFAULT() in most of the fox base methods of my subclassed set.
>For example in my CustomBase::Init()
>
>*---------------------------------
>local llRetVal
>
>llRetVal = dodefault()
>if llRetVal
> *-- Do some stuff
>endif
>
>return llRetVal
>*----------------------------------
>
>This is a bit the background.
>Well for the custom class I just added this code recently.
>Classes inhereting from my custom base working properly before went booming all of sudden.
>Lucky Fox displayed the call stack, so I was right on track to find the offending object.
>
>Removing the dodefault() - what in my case in fact called up to the Fox custom::Init() made my class working properly again.
>
>??? That damn strange fox.
>So I suspect the DODEFAULT() of being errornous.
>Which was already the case in VFP5.0 where DODEFAULT() called up the wrong hierarchy ending up with very strange results.
>BTW this was fixed in VFP5.0a so you should think VFP6.0 doesn't have any problems with that DODEFAULT().