>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?