Walter,

>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. And sorry Walter, but your irritation level is not my prime concern.

>If you did not need it for somereason does not mean anything to another person. If that person has to deal with a table with such name (beyond control), he/she might no have another choice. Another reason might be the performance advantage the mdot seems to have when a table with a large number of fields are open.

>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.

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.

>>If you don't have control over your development environment to forbid the use of a table/cursor name of this, thisform or thisformset then that's more a problem with your environment than it is with the VFP language itself.
>
>Very strange argument.

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.

>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.

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

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

>We are free to list those BUGs and expect the VFPT to look at it. It is eventually the decision of the VFPT to fix it, not yours.

Where do you see me having posted that Fabio should not have reported this? Where have you seen me say it should not be fixed?

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.