David,

DoDefault() "should" be put into every method you override. The "should" is based on the assumption that you are overriding to extend behavior. DoDefault() is what's used to cause the inherited code to be executed. In VFP you are free to put it at the beginning, middle or end of the method you override, depending on where it's appropriate for that code to execute. For me it's at the beginning about 95% of the time.

If you are overridding code to specifically prevent inherited behavior you should rethink your design, this is typically a sign of poor initial design.

VFP is a little different than other OO languages. Each VFP baseclass (textbox, editbox, commandbutton) have certain default behaviors to carry out routine stuff. For example Textbox.KeyPress takes the keystoke and adds the character to the .Value property. This default behavior occurs automatically at the end of all of your overridden code. NODEFAULT is used to prevent this automatic execution, it has NO effect on the method code that you write. NODEFAULT is also useful to change the sequence of when the baseclass behavior occurs. You may want to force Textbox::GotFocus() to occur before your override so you explicitly call it and add a NODEFAULT so it doesn't execute again at the end.

>>Yes, just add DODEFAULT() and don't worry about the default VFP code. This will prevent you from building a form that won't close because you put your code in the DESTROY method :-)
>
>OK. Although I'm a little leary about the default code. These default methods represent an interface between me and VFP (since I cannot change them) and it seems like the interface and functionality should be explicitly defined.
>
>>
>>And of course you can use NODEFAULT to prevent the default code. For example if you want to trap every "Q" and replace it with "Z", you'd put the code in KeyPress, but you'd have to also use NODEFAULT to prevent the "Q" from being processed.
>
>Now I'm a little confused. If I must use DODEFAULT() in order to insure that default code is executed when I change an inherited method, that would imply that the default code will not be executed if I do not use DODEFAULT()...so why would I explicitly have turn off default processing. Correct me if I am wrong, but I thought that in formal OOP, when an inherited method is redefined, it completely hides its ancestors up the class line from view (unless they are explicitly referenced by some means). Here you seem to be saying that adding code to inherited methods might pre-empt some 'default behavior' (thus requiring DODEFAULT(), while with others, adding code does not cover the default behavior thus requiring NODEFAULT.
>
>
>The lack of a formal definition of the interface to methods inherited from native baseclasses seems like a serious omission. Surely, I'm not the first person to be concerned with this issue?