>Like Dragan said, it is because of a bug that was advertised as a feature decades ago that now we have to deal with this. Other than that, of course, everyone tries to avoid the confusion of naming fields and vars the same. That's common sense, and not just in VFP. Unfortunately, the problem is that common sense (and your statement in caps above) may not, and sometimes it does not get you far enough. So, there is another option that would improve your chances, but you refuse to consider it because you claim it is not a perfect solution. So, I'll have to repeat again with complete certainty that

Ok, now we are getting somewhere. So we agree that var names and fieldnames should not conflict eachother, and this should be the 1st line of defense ?
If so, let take this further.

>Using mdot will absolutely guarantee that the aliased variable will not create any conflicts, anywhere. It is a true, complete, independent, and simple statement, easy to follow. Do what you will with it.

Absolutely, true from a technical pov.

HOWEVER

And this is entirely my personal choice and responsibility as technical director.

Since the fact that we use field and var naming conventions company wide and have identified that it is highly unlikely to have this particular problem, we have choosen not to bother with mdot.

So you might ask, why not go for additional safety?

If we decided to apply mdot, it needs to be enforced everywhere, not just what we change, but all code in the project or else it leaves the project in a state that does not provide any additional safety at all. As you have seen and I have be stating, it is incredibly difficult to make sure that it is applied everywhere (see VFPx) in the project. It will also mean that we have to look through the code of 3rd parties (we use half a dozen VFPX 3rd party code, like GDI+), not only once, but also with updates of those tools.

The next thing is that this needs to be enforced within the company to the programmers. They will make mistakes in that, that is a 100% given (VFPx Argument). Who is going to check that? Putting in all the extra resources (time/money) to enforce something that is only a theoretical problem is just not worth it. There is no ROI.

YMMV

Walter,