Neither is correct. The NODEFAULT statement sets flag that tells VFP do not perform default processing after event is finished. The DODEFAULT() is suppose to only execute code in the parent class not trigger the intrinsic native behavior. What Andy describes is obviously a bug.

>That is what I wrote also. But I now have an example where the intrinsic native behavior fires twice if I omit NODEFAULT, due to the DODEFAULT(). This indicates that there are situations that the intrinsic native behavior is tied to a subclass rather than to the chain of subclasses. To say it in other words, which of the following statements is true?
>1) The NODEFAULT statement only sets flag that tells VFP to not perform default processing for the current VFP subclass after it finishes.
>2) The NODEFAULT statement only sets flag that tells VFP to not perform default processing for the entire VFP event (including all subclasses) after it finishes.
>
>Having said all that, I think the clearest (and therefore best) article sofar on the topic of the odd behavior of NODEFAULT/DODEFAULT() is written by Andy Kramek on his weblog (http://weblogs.foxite.com/andykramek/archive/2009/04/11/8075.aspx). If his explanation is entirely right, then the next statement is true.
>
>2) The NODEFAULT statement only sets flag that tells VFP to not perform default processing for the entire VFP event (including all subclasses) after it finishes, UNLESS the first level subclass (that is based on the base class) contains a DODEFAULT(), in which case that line will invoke the default processing at the end of the code of the first subclass.
>
>The consequence is that the default behavior can fire twice if the NODEFAULT is not declared in the youngest child. That is the situation I'm encountering currently in one of my apps.
>
>