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 :-)

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.

>As a VFP newbie, I have just begun to use forms and I'm a little worried that if I define custom code for event methods of various controls on my form, the processing that would otherwise be done by the default methods inherited through the class hierarchy will not be done correctly.
>
>As a rule of thumb, is it good practice to place DODEFAULT() in every method inherited from VFP's native baseclasses to which I add custom code?
>
>Or is all of the really necessary processing for these events done regardless of whether or not I add custom code to a method with the form designer?
>
>I ask this because I've encountered some unusual behavior with one of my forms and I'm wondering if it is because one of the control methods I modified might no longer be performing some vital task that would otherwise be performed by its default counterpart inherited from the native baseclass hierarchy.
>
>If it is a good idea to execute DODEFAULT() in methods inherited from native baseclasses (which one intends to customize) how can one determine whether it's better to execute the default code before or after the new custom code?
>
>Is there a specification for all of the methods inherited by default from native VFP baseclasses? If so, where?