>
>I think you are confusing apples and oranges here. Most event methods have no base class behavior, they just run when the event that they are associated with occurs. IOW, a Click has no default behavior, as a form's Destroy and Unload have no default behavior. The Form's Init and load also have no default behavior. There is no need to use a DoDefault in an event if you write code in it.
>

In my other reply I give a few other examples of Event Methods with default behavior. The issues of not requiring DoDefault() here is a completely seperate issue. I don't need DoDefault() the first time I override any method in a class hierarchy. This is the behaviour that I don't like, the first time I overide a method I don't need DoDefault and the second time I do.

>It is important to understand that calling the event method does NOT cause the event to occur. There are many nonevent methods that do have default behavior as teh Relaese will release the form, the SHOW will show the form. etc.
>

I agree completely that calling the event method does not cause the _event_ to occur. But the event method is effectively an event handler and if for some reason I decide that I want to manually call the event handler (not recommended I agree) I would expect the same behaviour _as_if_ the event had fired.

>The other evetn method that I just realized has a defualt behavior is the KeyPress event which will process the keypress.
>
>The key here is that if you write code in the KeyPress you DO NOT override teh default processing of that key, you MUST issue a NODEFAULT to surpress the processing of the key.
>
>In this way the ddefault behavior of a base class method is different from inherited code in your class tree. The inherited code is overridden as soon as you write anything in a subclass method, but the default baseclass behavior is NOT overridden, it will occur after your code.
>
Yes, you hit the nail on the head here. This is completely inconsistent with any other OO language. I now have to treat base classes as a different beast than subclasses. I believe this was done to make life easy for those people who don't want to use the object oriented aspects of VFP. But ironically the first advice a newcomer is given is to subclass all their base classes. So, off the go subclassing all the base classes with not a DoDefault in sight and then the come to use their base classes. The second they try and specialize anything they either have to use DoDefault() everywhere in their specialized classes or they have to know when they are overriding a method that has already been overridden. And as for the users who don't want to specialize, well there's VB!

Anyway, enough ranting from me.
Have a good day,

Darrel