Hi David.

>> IMHO any appearance of any code in a method of a subclass should prevent execution of ANY AND ALL code up the hierarchy unless explicitly called by the overriding subclass code. That's how it works for any custom methods I write. <<

And this is, to an extent, true. Code in a method of a subclass over-rides any code in the parent class unless you explicitly issue a DODEFAULT() to execute the parent class code. The only behavior that it does not over-ride is the native VFP base class behavior unless you issue an explicit NODEFAULT. I do not understand the problem here.

And, if you will pardon me for saying so, I think that if one finds oneself constantly over-riding the parent class behavior, this is a sure indication that one's class design is flawed. JMHO < s >.

>> As a coder, I must know that both NODEFAULT and DODEFAULT() must appear in any event method where I want to completely control the execution of the default behavior relative to the new behavior I'm adding. Whereas, in methods I've added (...to my virtual base class,say), only DODFAULT() is required in subclassed methods thereof. <<

I'm a little confused here and am unsure of what you mean. This is fairly straight-forward. DODEFAULT() executes any custom code in the parent class. NODEFAULT suppresses native VFP behavior. So, yes, if you have a class that is directly subclassed from a VFP base class and you want your custom code to execute after the base class code, you have to issue a DODEFAULT() followed by your custom code and then followed by a NODEFAULT. Is that what you mean?

Actually, the only way (since VFP 6.0) that you can reliably cause the base class behavior to execute first, is by using the scope resolution operator. Something like this:

Textbox::GotFocus()
This.SelStart = 0
This.SelLen = 999
NODEFAULT

followed by you custom code and finishing with a NODEFAULT.

Marcia

Marcia