I'm not sure everybody will agree that it is a bug. It may be argued that it is by design. (But bad design in my opinion.)

However, I have done some testing on combinations. Andy had tested two levels. I have tested three levels. I have included here a picture with (hopefully all relevant) combinations and their results.
The tested event is a Textbox.Keypress event. This event has the advantage that a case of two occurences of intrinsic native behavior is visible because the keypress is doubled. E.g. when typing ‘a’ the result will be ‘aa’.

Subclass 1 is based on the native textbox base class. Subclass 2 is based on subclass 1. Subclass 3 is based on subclass 2. A test form only contains an object based on subclass 3.

Note: A subclass 1 object (e.g. in a form) can be recognized by its parentclass name. It will then be 'container' or 'textbox' or 'grid' or whatever base class name it's based on. An empty parentclass name indicates that the object was derived directly from a base class.

And yet another note: When adding an object that's based on a base class to a form (its parentclass name will be empty) and adding the line [ dodefault(nKeyCode, nShiftAltCtrl) ] to the keypress event, it will fire the intrinsic native behavior twice! So, this 'bug' is even possible if no subclassing is done.


>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.
>>
>>