David,

>>I really get irritated by such statements.

>The statement was made, just as a frame of reference that I am not a "toy" programmer. I've done a lot of serious development in VFP and I've never ever had a conflict with this and thisform.

Why would anyone doubt you're a toy programmer? Why is it needed to express you're not a toy programmer? The reasoning in your your reply should say enough. And somehow I feel your degenerating Fabio as a Toy programmer. Well for a Toy programmer he is able to produce an impressive list of VFP bug and other problem which is unseen before in this VFP community.

>And sorry Walter, but your irritation level is not my prime concern.

I understand that, however it is meant to give you a sign that your answer might be explained in a negative way. Not only by me, but other people also. What you do with it is entirely up to you.

>>I've litterly written hundreds of thousands lines of VFP code, but I still might not encounter a situation which you might use as an argument to code differently. These types of statement IMO show a kind of arrogance that should be banned from the UT.

>Well I've stopped doing line counts of code. It's a code metric that is hardly releveant in O-O systems. My tens of thousands was a rather conservative estimate I assure you.

I'm sure it is, and I don't doubt that. However I don't see the relevance of this statement. Quantity certainly is not a measument for quality, esspecially in this field. I know too may examples of people who have been programming all their lives but could not produce a decent piece of code.

>There are always ways around conflicts (use SomeBadName alias AMuchBetterName is one very simple one), sorry that you percieve my argument as arrogant, that's more your problem than mine.

Well don't try to build a local view on such table, because VFP insist open that table by its native name. And how about fields named THIS or THISFORM?

>It's not strange at all. You can make a company wide "rule" that says don't use this as a cursor or table name. Which prevents the problem on new code being developed.

If you come to an enterprise environment where you don't have anything to say about this and you want to deliver the first VFP application, you might not be in a position to say: Let's make this a company rule. And yes, I've been in such situation where applications where upgraded from FPD 2.x to VFP where different applications run on the same data and you are nowere in a position to change anything in the database structure.

Let it be clear. I really don't want to be in a situation where I have to use m. in such cases. Where ever I can, I avoid the use of m. at all. However, I do recognize people use different naming conventions and programming styles, and I recognize you have to take controversial routes from time to time.

>>So when upgrading from or interfacing with Fox2.x, possibly dbase or clipper in which these names are not a problem, it still is a problem of the environment. Are you going to tell the client this ??

>No, I'd workaround it one of the other available ways.

For example using a m. ?

>>The C5 errors should be solved by the VFPT, period.

>If you've bothered to read my posts I've said the same thing.

My appologies. I did not realize we had the same standpoint. Sorry.

>All I've said is that Fabio can indeed work around this posted bug by dropping the m.this construct. Considering that VFP9 is still several months away, and that there is some probability that this C05 is low enough on the priority scale that it might not be fixed in VFP9, then it would just seem prudent to me that Fabio solve the problem in the manner that he currently has available to him rather than letting his app continue to C05 crash.

I agree.

Walter,