<snip>
>But what of m.this and m.thisform ?
>vfp code behaviour "suggests" that these should mdotted as well,
>on the other hand both are vfp keywords and
>as such shouldn't be used as field names in the first place<g>.
>

_TALLY,this,thisform,thisformset are all VFP "keywords".
which thing is? how they are implemented within VFP?

You must define them with the eyes of a physics observer,
than what we can observe?
We can only observe what ago the VM of VFP.

_TALLY it is a _TALLY System Variable, RW !

CLEAR
_tally = -0x80000000
? _tally,-0x80000000  && <=== it is a C unsigned integer
_tally = -1
? _tally,-1
_tally = 0x1FFFFFFFF
? _tally,0x1FFFFFFFF

LOCAL _TALLY  && ERROR
PUBLIC _TALLY && ERROR
PRIVATE _TALLY && ATTENTION, no error ( probably a parser bug ) 
? m._tally    && <==== it is not a application variable

For This,thisform,thisformset I call to them therefore
- protected ( i cannot release/define, and they are ro )
- private ( they are born and they die like a private variable),
- application variables
( VM use the standard routine for search a identifier,
with or without m. prefixed, VFP jumps or it does not jump "SET FIELDS GLOBAL" list )
- they are not system variables ( in fact doc don't define what they are )

PRIVATE this && <== error! this is the proof, VFP don't want put this into the scoped variables list, because the VM search in "this" on the scoped list
? m.this && this is ok
? this && this search into SET FIELDS GLOBAL, then into the Scoped VarList

>Here I am consciously "lazy" as it enhances readability [for me].
>The benefit is for me worth the risk. So viewed from "code correctness" you are correct,
>but from best use of budget it might be more cost effective to use other approaches.
>
>regards
>
>thomas

budget ? which budget