Confuses the living sh*t outta me, too. But, hey, I guess the rule of thumb here is if you don't need custom functionality in the subclass, don't mess with it.

>Ok, this wierd. I just read this post and said "Hey, I don't get the xxx = vNewVal when I edit the method." So I went back looked and I don't, all I get is LPARAMETERS vNewVal.
>
>However, I added a space to the code, ran the form, and the parent code doesn't run (as expected). So I went back, selected my object and right-clicked in the property sheet and click 'reset to default'. Sure enough, it now shows

LPARAMETERS vNewVal
>*To do: Modify this routine for the Assign method
>THIS.ATEST = m.vNewVal

What's up with that?
>
>The confusing part is that 'reset to default' is different than the original default.
>
>Also, if I delete that code, then go back to edit it later it only shows the LPARAMETERS again. Wierd.
>
>>Oh, I understand the reasons, it's just that it can be misleading to see your subclass show the LPARAMETERS and xxx = vNewVal code when the Parent class might have entirely different code. This is unlike any other custom method.
>>
>>>John,
>>>
>>>No it's a feature. Your methods work just like the VFP ones do. If you edit a keypress the lparameters statement is there for you already. IN VFP 6 your added methods work the same way. If you don't want to override the behavior then just leave it alone.