Visual FoxPro Reference | Hackers Guide to Visual FoxPro 7.0

DoDefault(), ::

This function and the operator composed of two colons (called the "Scope Resolution" operator by the docs) let you call methods higher up in the class hierarchy. You use them most often when you want to augment a method to do everything the parent class's method does, plus some more.

Usage

uReturn = DoDefault( [ uParmList ] ) uReturn = ClassName::Method( [ uParmList ] )

Parameter	Value	Meaning
uParmList	List of expressions	Parameters to pass to the method being called.
ClassName	Name	The name of the class whose method you want to call.
Method	Name	The name of the method to be called.
uReturn		The value returned by the method called.

DoDefault(), added in VFP 5, calls directly up the class hierarchy. That is, it can call only the parent class's version of the method you're in. The :: operator gives you more flexibility than that, but most often, you use it the same way. You can, in fact, call any method that's in the class's inheritance tree. You can't call a method that belongs to a class the current class doesn't inherit from.

Despite the fact that :: is more flexible, it's better to use DoDefault() when you can because it doesn't tie your code to a particular class or method name. Your code is more reusable if you allow the DoDefault() to find the appropriate class hierarchy for the method it finds itself in.

The initial release of VFP 5 had a bug in DoDefault() that caused a problem when there was a method in the hierarchy that didn't have any code. If you issued DoDefault() in a method and the same method in the parent class was empty, the method in the parent class's parent class executed twice. The bug was fixed in VFP 5.0a.

VFP 5 and early versions of VFP 6 have a truly insidious bug as well. It occurs if you use DoDefault() in a method that automatically calls the same method of other objects (for example, a form Refresh, which automatically calls Refresh of member objects, or KeyPress when KeyPreview is .T., which automatically forwards the keypress to the object with focus) and there's no code in the same method of the parent class of the original object (the form, in the examples). In that case, the keyword This in the other methods of the contained object(s) (the member objects in the Refresh example, the object with focus in the KeyPress example) doesn't refer to the object whose code is being executed, but to the original object whose code had the DoDefault() (the form, in the examples). This was a truly ugly bug and we glad it got exterminated.

Example

DEFINE CLASS CloseButton AS CommandButton    * Set appropriate properties up here    * including    Caption = "Close"      PROCEDURE Click       ThisForm.Release    ENDPROC   ENDDEFINE   DEFINE CLASS ConfirmCloseButton AS CloseButton      PROCEDURE Click       LOCAL nResult       nResult = MESSAGEBOX("Closing Form",33)       IF nResult = 1    && OK          DoDefault()          * Or, in VFP 3          * CloseButton::Click       ENDIF    ENDPROC   ENDDEFINE