Hi George,

I respect your opinions, but please don't mind I express my different views.

>I haven't ever experienced a crash because of the mdot issue.

It is because you do not use field names like TcTable, PcItem, LcDesc, TcOrder, etc (all of them are variables, without m., found in xSource). I won't be surprised if such names are found in other programmers tables, particularly those migrated from FPD and FPW (in which field width are limited to 10 characters)

TC, LC, PC, GC, LN, and so on, are good candidates for describing business items. For example, somebody may define a field LcDesc for Letter of "description for letter of credit", a PcItem field for "component items of personal computer", and a TcOrder field for "sorting order of table of contents"

The most serious thing is that the name crashes do not necessarily lead to obvious problems. Issues may be hidden until users complain or tragedies emerge. For example, the following code (found in RI Builder) may run without any problem in development even if a TcOrder field does exist, but lead to wrong result in the future.

IF NOT EMPTY(tcOrder)
	...
ENDIF

>If you don't like the way the code is written, then, in most cases, you have the source, so change it. I have.

VFP are used by a large number of programmers of various levels. For programmers of elementary and average levels, they may not be aware of the issues. Even if problems are encountered, they may not know the reason or how to solve them. Anyway, it is not a simple job to add "m." back to the variables in the sources and rebuild the tools.

>What we're talking about here are tools that are provided, free of charge, with VFP.

Actually they are integral parts of VFP, which are necessary for our development work. They are different from other free public domain tools which claim "They are provided in an 'as is' basis. Use them at your own risk."


Ben