>>>After
>>>* rebooting my PC
>>>* cleaning out some junk items out of the resource file
>>>* cleaning out temp folders
>>>* explicitly COMPILE of the PRG
>>>The following:
>>>

>>>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 = m.THIS				&& 1
>>>		WAIT WINDOW TRANSFORM(m.oObject.Value)	&& 2
>>>	ENDFUNC
>>>ENDDEFINE
>>>

>>>appears to work in VFP6.
>>
>>
>>The lesson learned is that you will have to use mdot in a lot more cases that people tell you. You'll have to investigate where it is mandatory and where not.
>>
>>Yes you can use m.THIS and solve this problem, but really, do you know one piece of public code that does adhere to this, or anyone who recognizes this problem? Do you agree, It will be very hard to spot the error if there was a conflict because you used THIS in stead of m.THIS ? I know I would personally curse anyone in his right mind solely relying on mdot to make the distinction.
>>
>>The problem of system variables has the opposite problem.
>>using a field _Cliptext cannot be accesses without using its alias. If you try you always will get what is in your clipboard no matter a such field exists in the current work area.
>>
>>_Cliptext will always get you the _cliptext content, m._cliptext would even error out if the memory variable does not exist.
>>MyTable._Cliptext is needed to refer to the content of the fields.
>>
>>If you do a scatter memvar, _Cliptext and m._Cliptext return different values. So who does know this? would it be obvious if you are debugging a problem?
>>
>>And this applies to most system variables, including ones like _Screen and _VFP.
>>So with THIS, and THISFORM you can use mdot to make sure you're referring to the right object, however for _VFP and _Screen you can't do that.
>>
>>Is this logical?
>>if you go this problem in your code, how hard would it be to be able to spot it?
>>
>>The fact is that mdot has a messy implementation on those borderline cases and from a practical pov it is unrealistic to protect yourself from variable - fieldname conflicts just because of this.
>>
>>it pays of tremendously to make sure variables and fielnames to have a different naming convention so it is absolutely clear what you are dealing with when you read the code.
>>
>>Walter,
>
>
>Only to the human reader, not the compiler.

The compiler does not write and debug code.