Hi Alan,

Ryp already commented on this but from the VFP Help Topic Controlling Access to Variables:

Accessing Variables
If a variable has the same name as a field, Visual FoxPro always gives precedence to the field name. You can reference the variable using m. or m-> plus the variable name, as in the following examples.

? m.cFname
? m->cFname && print value in cFname
? cFname && prints contents of field cFname

So, at least the behavior is documented.

>I had a very strange situation happen to me the other day, and while I've corrected it, I'm wondering if anyone else has run into teh same thing. It appears to be a bug in VFP - I'm using VFP6 with SP5.
>
>I have a function that I've been using for a long time that pulls information out of a string by position between delimiters. The signature looks like this:
>
>* Function to return a value from a text string by position
>FUNCTION fGetVal
>LPARAMETERS cLine, cPos, cType, nLen, nDec, cDelim
>* cLine - the line that contains the required info
>* cPos - the position number in the line of the data required
>* cType - the type that the data will have to match
>* nLen - number of characters to bring back - ignored if not type 'C'
>* nDec - the number of decimals, defaults to 0
>* cDelim - character that separates the fields - defaults to a comma
>
>This function has been working fine for a long time, but suddenly in one project, it didn't. It was returning an empty string when it should not have been.
>
>When I stepped through it in the debugger I discovered that even though I was sending it the correct arguments, it was taking the 'cType' parameter value from a field called cType in the view that was current at the time.
>
>I was doing lcVal = Alltrim(fGetVal(txtString, '5', 'C', 100)) - nDec and cDelim default if not sent. The 1st 4 arguments are required.
>
>In the debugger, the value of the Parameter 'cType' was 'Sample ', which was the content of the cType field in the view in the current workarea.
>
>The fix was simple - changing the parameter name or changing the field name worked equally well. I opted for changing the field name in this case.
>
>Has anyone else run into this scary little bug?
>
>Alan