>>>... Of course, for some time now, I've been using mdot, so all my programs since then are share-safe in that respect. If I were to share any utility programs that you'd find helpful, you could use them with confidence.
>>>*
>>
>>Nope.... Again if there are even loopholes in the vast GDI+ libraries (on VFPx) why should I be confident with yours unless I make sure my fieldname convention would be such it won't conflict with it ?
>
>Unfortunately, your field schema does not guarantee anything. You said it yourself that it would work only in combination with your variable naming convention. So, either one makes sense only in combination with the other, and only within the namespace of your project. Any outside program not using mdot could create conflicts since it is not aware of your field naming conventions...
>At this point, I think I squeezed every possible answer, at least twice :) I'm not sure what else I can say... Enjoy your weekend!

Yes it does. just like hungarian notation, its quite unlikely that variables are called m.ORD_CREATEDATE unless specifically using SCATTER MEMVAR. The fieldnaming convention is the best defence of all. You might argue that it theorectically is still possible. Let me show you that the loophole in mdot is far bigger than that.

>Sorin
>
>Update: I just looked over the programs in the System GDI+ project. It's all mdotted; no loopholes there. So, apparently most people doing this kind of stuff are actually writing code responsibly.

Look this is the pitfall everyone falls into. FALSE SENSE OF SAFETY

GDI plus library. System.drawing.prg, Line 1413:
toRect.GetExtent(@lnX, @lnY, @lnWidth, @lnHeight)

Though the library uses mdot quite consistenly, on this line it does not, probably on the (wrong) assumption that VFP would know they should be variables. Instead an error shows up when a table/cursor is selected with one of the variables as a fieldname

Line 1669, several lines without mdot where they need to be used.
m.hdcCompat = xfcCreateCompatibleDC(hDC)
m.hbm = xfcCreateCompatibleBitmap(hDC, m.lnWidth, m.lnHeight)
m.hbSave = xfcSelectObject(hdcCompat,hbm)
m.xfcBitBlt(hdcCompat,0,0,m.lnWidth, m.lnHeight, hdc, 0, 0, SRCCOPY)

Line 374, system.prg of the GDI library, forgotten mdot
BINDEVENT(m.toBindObject, m.tcBindMethod, This, "Fire", tnFlags)


And you know there are more,, if you look for it.
I can guarantee that most VFP projects regardless of using mdot or not would crash on a selected cursor that has the fieldname "THIS" in there.

But in defense of GDI+, since hungarian naming convention is used, the chance of this being a problem is rather slim.. You see why it is wise to use naming conventions.
But you see it is entirely possible to crash or malfunction this with a cursor with fieldnames like tnflags, hdc, lnwidth or lnHeight in there.

Bottom line: IT IS INCREDIBLY HARD TO USE MDOT TO PROVIDE FULL PROTECTION AGAINST NAMING CONFLICT. If you control the database side of thing, IT IS SO EASY TO USE NAMING CONVENTIONS TO PROTECT AGAINST NAMING CONFLICTS


YMMV, but to me reality (Public VFP sourcecode) is this mdot is providing a false sense of safety.