>>Why not? Because our coding convention is such and I won't allow for a change that has no merit and would be full of loopholes just as the code on VFPx shows. Its easier to code without mdot than force mdot everwhere where needed. That is why.
>
>Am I wrong in reading that you'd agree to use mdot in code that you'd share with others?

Yep..... that is, you are wrong...

>>>Otherwise, what is your convention for naming variables? I missed that, if you posted it before.
>>
>>Prefix with type, then camelcase the rest of the variable name, like
>>
>>nT, cPatientName, lVisible, etc
>
>I use something similar out of habit, though I cannot find any other justification for it. It does not guarantee anything. Actually, I used to have a one more letter prefix for scope, and since most of my vars are LOCAL, they're all named lSomething. Like lcPatName, ... (that is the small L for Local). Since it does not create any semantic value, it looks foolish to have vars prefixed with "l", but now that I think of it, it would have a benefit; it reduces the risk of conflict to only clashes with field names prefixed with L. 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 ?
So far I have not found any 3rd party library that is conflict proof. All of them contain flaws. So there is absolutely no basis to trust any piece of 3rd code to be conflict proof.

Walter,