>>>>The problem with a table with many fields / many tables is, VFP will first run against those, then against the list of variables. So for access mdot makes sense. But for assign a value or accessing something that simple could not be a field like a method or array there it does not much sense to use it.
>>>
>>>Lutz,
>>>
>>>Whether on the left side of a statement or in an expression, the variable is the same. I fail to understand why one would choose to reference it in different ways deliberately.
>>
>>Unused code is just bloat and adds nothing to usefulness. I can accept it speed up on several location. But makes code less readable. So I optimize? And mdot where there is no other way then variables could only make code slower. It must be dealt with.
>>
>>Best way for development is to skip mdot at all, it's super awkward (Just as adding alias for any field even if the alias is in scope. In fact it is aliasing memory variables) and in most cases VFP works without. It might be wiser to SELECT 0 and run variable based code without mdot instead of this oddness. In that case there is no field name, isn't it?
>
>Obviously it goes without saying that prior to doing this you should retrieve the current workarea before you change it, and restore it afterwards. There could still be a danger if there are any conditions that might cause the current workarea to change unexpectedly (e.g. when you've got a grid that is in focus).

Any method / procedure using SELECT [SQL] should do this, except the change of the workarea is the use of the method. Events not doing this are fine way to create heisenbugs

For that, any code should lay an invisible frame on top of _SCREEN, so no fool could play with grids or other UI objects. Hide Toolbars.
;)