>>Hi,
>>
>>I know I should know the answer to this question after using VFP for 10 years but let me ask just to be sure.
>>
>>I have a form class (child class) based on another form class (parent class). In the LOAD method of the child class I have a bunch of code and then I always have DODEFAULT(). The parent class has Nothing in the LOAD method. I believe that I really don't need this DODEFAULT() in the child class LOAD method and therefore can remove/comment this line. Am I correct?
>
>If you have absolutely no code, the parent method is run. I really see no reason to have that single line - but if you later add code - in your example, to Form.Load() - don't forget to include a DoDefault().
>
>If you DO include DoDefault(), for any reason, additional considerations may apply. The following explanation is not specific to the Load() Method, but to inheritance in general.
>
>1. Any value returned by the parent method may have to be passed up to the next level. Say you have a method SaveRecord(), and this returns .T. if the save was successful. You have at least three methods involved: SaveRecord() for the form you are editing, SaveRecord() for the parent class, and some method that invoked SaveRecord() and wants to know whether the record was saved successfully. Here is an example.
>
>

>local llSuccess
>llSuccess = DoDefault()
>* Additional code goes here
>return llSuccess
>

>
>2. Additional parameters, received by the child form/class, may also have to be passed to the parent class. Expanding the above example:
>
>

>lparameters tcSomeOption
>local llSuccess
>llSuccess = DoDefault(tcSomeOption)
>* Additional code goes here
>return llSuccess
>

>
>
>So, having the un-needed DoDefault() may have pros and cons.
>
>Pro: You already have the DoDefault() there, and won't forget it later.
>
>Cons: A line that really isn't needed; also, there may be the additional complications I mentioned, depending on the method.

Hilmar,

Thank you very much for the detailed input.