>>>When I write the code I will never have the problem of using the m.dot or not using the m.dot. My coding convention uses the above rules. However, when we use classes that the community has written now we could have potential naming conflicts between variables and fields. So having the compiler enforce the rules is preferable.
>>>
>>
>>Just want to point out that the Hungarian naming convention isn't infallible. While it's a bit of a stretch, it's certainly possible to have a field name lOrange and a variable named loRange. I haven't gone hunting for other examples, since one makes the point, but I'll bet there are others that are plausible.
>>
>>In my view, VFP developers should always use mdot where there's any chance of ambiguity. That's even more important for tool writers since they have no control over the naming of fields in tables their users create.
>
>I agree with you when using a class or code that the community has contributed. I would not create a field named "lOrange" - it would just be "Orange" (I don't use the Hungarian notation for fields). The variable would always be loRange; so naming conflict for my coding development based on my standards. So far I have not run into a naming conflict since developing from 1990 timeframe in FP/VFP.
>
>But the problem is very real when using a class from the community. Now a naming conflict could occur. I have thought about this for the workbook class that I wrote on VFPx but I have not applied the m.dot to it. Is there a utility that will scan the class and update all variable references with a m.dot? I am not a user of Thor (I still use the older PEM editor that Jim wrote) but possibly it has this functionality... If so can you point me to it? I would then use it to change the class code at the time that I upload an update to VFPx (I still don't want to use the m.dot for my own applications).

Of course, you can still have problems (especially if word breaks could be ambiguous) -- humorous example would be the "pen is stuck" note
http://mattdavidky.blogspot.com/2011/05/pen-stuck-inside-printer.html
You can't avoid ambiguities with camel-case nor Hungarian notation when case insensitivity is involved -- though on the other hand camel-case and Hungarian notation could help with readability.

the one time I found m.dot to be problematic was with WordTech's Quicksilver. It occurred in variable assignment statement with a variable where the variable name specified used m.dot -- in this case the variable created had the "m.dot" as part of the name, requiring you to use double m.dot to access it. Quickly learned to avoid using m.dot on left-hand side of assignment statement (where m.dot really wasn't necessary -- there was no ambiguity in that context). Avoiding m.dot altogether would indeed avoid this one specific "undocumented feature" -- but it would trade it off for a much wider category of problems involving ambiguities.