>>* a "better safe than sorry" measure -- no matter how careful you've been with design with naming of variables, tables and columns, once you start having "foreign" code or tables, you can't be sure conflicts can't happen.
>>
>>I think it is the opposite. Let me explain.
>>
>>In our database all fieldnames are unique because for each table we have a three character prefix + underscore.
>>The bonus is that wherever you see a fieldname you not only can identify its a field, but also the table where it came from.
>>It really is refreshing not having to use aliases in joins in SQL statements and really pays of in audit trails as well.
>>
>>For calculated fields we don't have the prefix, a name without any naming convention. For variables we use a variation of hungarian notation. Possible conflict between fields and variables are reduced to a minimum.
>>
>>Now the other side. I've already outlined the borderline cases with THIS, THISFORM and VFPs system variables.
>>But a more realistic problem is the following.
>>
>>When you are debugging a piece of code, and encounter something like the following
>>
>>

X = ALLTRIM(Zipcode)+" "+ALLTRIM(City)

>>
>>How the hell do you know whether the intention was to use a fieldname or variable if you're using the same naming convention? Suppose it needs to be
>>

X = ALLTRIM(m.Zipcode)+" "+ALLTRIM(m.City)

>>
>>How would you know without having to dig into the context of the code? With different naming conventions between variables and it would be.
>>
>>

X = ALLTRIM(Dem_Zipcode)+" "+ALLTRIM(Dem_City)

>>
>>vs
>>
>>

X = ALLTRIM(cZipcode)+" "+ALLTRIM(cCity)

>>
>>There is absolutely no question what the intention was.
>>
>>
>>Now let me give me some real world examples of where 3 party libraries got problems with mdot.
>>
>>The GDI+ libary. system.drawing.prg. One of the libraries which have applied mdot in the most consistent way.
>>
>>

>>			m.lhBitmap = This.GetHbitmap(CREATEOBJECT("xfcColor", ARGB_LightGray))
>>			m.lhBmp = CopyImage(lhBitmap, 0, 0, 0, 0)
>>			DeleteObject(lhBitmap)
>>

>>
>>ARGB_LightGray is a constant so has to be applied without mdot, but lhBitmap is not. It clearly is an error. Imagine you have a table open with a field lhbitmap. It would clearly would cause problems.
>>
>>Bottom line, my point is that mdot creates a false sense of safety.
>>just make sure the names cannot conflict and you don't have to worry.
>>
>>Walter,
>
>I get your point -- indeed blindly applying mdot is NOT a solution. In general blind adherence to any rule is generally not a good idea. As I implied earlier -- your rule of "just make sure the names cannot conflict and you don't have to worry" could end up falling apart once "foreign" code or tables are introduced. Also your rule often doesn't apply when you're dealing with code you may have inherited. The other point is that your examples also tend to be more "edge case" than the more common situation (i.e. I tend to think of calls to system API functions more of a "special case" situation). Perhaps Mike may be interpreting your argument as being a reason for abandoning mdot altogether?

That is exactly what he says. He will go out of his way to avoid using it specifically because he does not like how it looks which is childish and stupid. My position is it is absolutely required in many cases because of the way many apps have been "built". It is part of FoxPro's functionality. Naming conventions are not. Further he goes out of his way to actively deny my position. I have had enough of such low-brow idiocy. So, I'm a bad guy for defending myself against repeated harassment over the years? Good. I now see there are people I thought were friends, but are not worth my time. Funny how few have shown any support. Some wonderful community.

Tamar I have known for years. She recently threw the term toxic masculinity at me. Guess where it really belongs?

>
>My first impression would be that an mdot probably should be added for the reference to "lnhBitmap" in the calls to CopyImage() and DeleteObject(). The mdot on the left-hand-side of the assignment is probably not needed.
>

>	m.lhBitmap = This.GetHbitmap(CREATEOBJECT("xfcColor", ARGB_LightGray))
>	m.lhBmp = CopyImage(m.lhBitmap, 0, 0, 0, 0)
>	DeleteObject(m.lhBitmap)
>

>
>I usually tend to not apply mdot on the left-hand-side of an assignment statement, and apply mdot on the right-hand side. I also try to make sure that whatever symbols that I'm applying aren't coming from a #DEFINE. [shrug] But this is sort of what you've got to live with with the way xBASE had evolved (i.e. it was meant to be a user application, not a software development tool).