NODEFAULT prevents execution of VFP base class code (e.g. base textbox KeyPress, for example)

DODEFAULT() executes the parent class code.

So, the placement of NODEFAULT doesn't matter, but the placement of DODEFAULT() matters.

>The pieces of code below both have dodefault() and nodefault, but their order differs. Some would argue that the effect is entirely similar, but is this always true?
>

...
>dodefault()
>nodefault
>...

...
>nodefault
>dodefault()
>...

>I have always thought of NODEFAULT as a toggle that will prevent the intrinsic native behavior of the event, which will fire after all code. But I have also always thought of the intrinsic native behavior as firing ONLY in the topmost (youngest child) subclass. That is, all parentclasses that are visited via DODEFAULT() will not fire the intrinsic native behavior.
>
>Now I have to deal with a subclass that appears to fire the intrinsic native behavior twice. The youngest child contains no NODEFAULT, so the intrinsic native behavior fires at the end of the event, but it also appears to fire as a result of DODEFAULT() in the parent class. This is odd, to say the least. I have searched here and there. There is some debate as to whether it is a bug or a confusing and badly documented design feature.
>
>I have alos tried to discover whether or not there is a difference between declaring NODEFAULT prior to DODEFAULT(). The idea is that this may actually also prevent the intrinsic native behavior in the parent class(es).
>
>Who can help?