>Dragan,
>
>>Oh, I got it now: the nodefault stops all code, native VFP and custom parent class code from running, and then DoDefault() calls the parent class code without the native VFP behavior.
>
>Not exactly.
>
>NODEFAULT only prevents the automatic execution of the VFP Baseclass code (native behavior), which normally executes at the end of our overridden method code. NODEFAULT only does something detectable for VFP baseclass event methods that do something like Textbox::KeyPress. For methods like CommandButton::Click() it doesn't matter because the the VFP code doesn't do anything as far as we can determine.
>
>Overriding a method with any code causes the inherited code we write higher up the class tree to not execute unless it is explicitly called with a dodefault( [args] ) or ParentClassName::MethodName( [args] ) call. This does provide us the flexibility to execute the modified method when we want:
>
>Case - postfix overridden code
>

   dodefault()
>   ... && the additional code

>
>Case - prefix overridden code
>

   ... && the additional code
>   dodefault()

>
>Case - some prefix, some postfix
>

   ... && the additional code
>   dodefault()
>   ... && more additional code

>
>Case - lose all inherited code
>

... && the only code

>
>
>Dodefault() has IMHO done some screwy things relative to the VFP Baseclass code and is the cause of what Stacy initially had to compensate for. And there were some changes to the way this worked between VFP5 and VFP6. I, and this is a personal opinion, don't think dodefault() should ever cause VFP BaseClass behavior to execute. If we need to force VFP to do it's behavior before the end of processing we can code:
>
>

nodefault && prevent automatic
>... code
>VFPBaseClass::Method() && force it now
>... code

Thanks for the explanation David...