In message #1417319 I wrote some conclusions about the bug/feature/quirck in VFP's DODEFAULT/NODEFAULT model. In this thread I'd like to continue.

The DODEFAULT() function is supposed to 'execute the parent class event or method of the same name from within a subclass'. This is the official text from the documentation. However, there's a bug/feature/quirck in VFP's DODEFAULT/NODEFAULT model. If DODEFAULT() is done in a subclass that's based on a vfp base class, then the intrinsic native behavior will fire twice. See also the screenshot of a table I created that shows several relevant scenarios.

How can you know whether or not a subclass is based on a base class? A rule of thumb is to look at the Parentclass property. If it's empty, then it is directly derived on a base class. This is the case in a form when adding a base class. If it shows the name of a base class (e.g. 'Textbox', 'Grid', 'Container'), then it is the first level subclass. In other cases it is apparently based on a subclass.

So, I look at the Parentclass property. And I see something that puzzles me. But before I tell you what puzzles me, I need to further prepare you. Here are some other 'definitions', derived from the official doc.

* Object.Baseclass  : The name of the vfp base class on which the object         is based.
* Object.Parentclass: The name of the          class on which the object's class is based.
* Object.Class      : The name of the          class on which the object         is based.

Suppose there's only one subclass. A representation in the Class Designer would be:

* object\
*        \baseclass

As I read this:

1) The object is based on a (vfp) base class. Object.Class will be identical to Object.Name and Object.Parentclass will be identical to Object.Baseclass.

2) The rule of thumb (look at the value of Object.Parentclass) will help here. I'd expect that putting DODEFAULT() in the object's method would fire the intrinsic behavior twice, due to the bug/feature/quirck.

Suppose we use this subclass in a form. A representation of that model in my perception:

* object\
*        \class\
*               \baseclass

As I read this:

1) The object is based on a class that is based on a (vfp) base class. Object.Name will be an extension of Object.Class. E.g. 'txtBase' will become 'txtBase1'. I'd expect that Object.Parentclass would now be identical to Object.Class. In the example, Object.Parentclass should be 'txtBase' which is the base of Object 'txtBase1'. However, my finding is that it is identical to Object.Baseclass. So, rather than referring to the parent of the object, it appears to refer to the parent of the class that the object is based on. By the way, this is consistent with the 'definition' of Object.Parentclass given above.

2) How about coding in the object's method? I'd expect that putting DODEFAULT() in the object's method would NOT fire the intrinsic behavior twice, since it is not directly based on a base class. However, the rule of thumb puzzles here, because Object.Parentclass is identical to Object.Baseclass, which indicates that we can expect the bug/feature/quirck of DODEFAULT().

Did you follow me? Are you still reading?

My hunch is that the rule of thumb is inadequate. A better one? How about:

The bug/feature/quirck of DODEFAULT() can occur ..
if ( Object.Parentclass is empty )
or ( Object.Parentclass = Object.Baseclass AND Object.Class = Object.Name )

That's rather a rule of two, or even three, fingers. Hope you can remember it. Or shoot at it.