>>mdot is not the magical silver bullet to avoid conflicts between field and 'variables'
>>
>>Consider the following example
>>

CREATE CURSOR Test (This i)
>>INSERT INTO test VALUES (1)
>>
>>m.xo = CREATEOBJECT("X")
>>m.xo.Foo()
>>
>>DEFINE CLASS x as Custom 
>>	Value = 2
>>
>>	FUNCTION Foo
>>		SELECT Test
>>		m.oObject = THIS
>>		WAIT WINDOW m.oObject.Value
>>	ENDFUNC
>>ENDDEFINE
>>

>> ...
>>Walter,
>
>Hrm... interesting... After I change the line
>

		m.oObject = THIS

>to
>

		m.oObject = m.THIS

>I'm now getting a C0000005 error. 🤔
>(this is under VFP6 SP5)
>
>In VFP 9 the crash doesn't occur.

Walter uses fringe examples as reasons not to use mdot, but then cannot accept the fringe argument that a field name could easily be latest, and crash because somewhere in the code, someone named a var the same. I am using mdot where it is required to safeguard my code from the crappy coders that I have encountered regularly.

If you think there are no crappy coders, go into the Windows operating system and do a find across the entire driver for .ini files. Sort the list by date or folder and why are we waiting for it to search the whole system again? What idiot decided that is proper? Not even Microsoft is great, so others are worse. I was the one that embarrassed Microsoft into buying Fox software, because way back then what Fox did, which I totally approve of, is they squeezed every ounce of safety and speed out of the code, making dBase look bad, and what became Access and SQL Server. It was Fulton's science that won the day, not some idiot's opinion about what makes good looking code.