Well, actually, my first exposure to OOP was VFP 3. It's poor performance and bugs led my company to investigate Delphi 2. IMNSHO, Delphi has a better OOP implementation than VFP. However, VFP excels in developing LAN based database apps; thus, with that said, understand that I am not trashing Fox. My original post was rhetorical in nature and sought an understanding of the reasoning behind VFP's approach to this...

For you to say that neither approach is right or wrong is a value judgement in itself...

>Six of one, 1/2 a dozen of the other. You're first experience was with one default behavior and so that seems natural to you. My experience is the opposite. Neither is right or wrong but a matter of knowing your tool IMNSHO.
>
>Regards.
>>That's the type of theory explanation for which I was looking. My problem resides mostly with the Visual Classes. We have our standard form for example that contains a SET EXCLUSIVE OFF and SET DELETED ON in the LOAD EVENT. A developer on staff was getting a "File in use" error in a form. Without looking at in detail, I posted a message here thinking that it was a Data Environment problem. After Cetin provided a suggestion to check the SET EXCLUSIVE, a light clicked on over my head. I found that my VFP newbie forgot to "DODEFAULT".
>>
>>I've never understood why this was not the default behavior in subclasses. My other OOP experience is with Delphi where adding code to methods automatically includes an INHERITED keyword. The developer has to make a conscious effort to override in Delphi. That just seems more intuitive to me.
>>
>>In a team environment where everyone may not know nor have the time to study the custome code in the parent methods, I would think that a requirement to implicitly state to override would result in less programmer error...
>>
>>Thanks for the input...
>>
>>Jack