Logo

Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.

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

See Also

Class, Parent, ParentClass, This