Jim everything is debateable, I used to be a Strong VFP defender in the past now for me is a PITA everytime I need to go back from VS.NET into VFP, The only thing I miss is the easy of data management I use to had in VFP, the CRL inside SQL 2005 have come to help a litle but isn't still close to what we could do with VFP data.
About bad programing that should be an excuse to not use something.
I used #DEFINES on .h files for messages, and other const values so when I had to change something I knew where to go, the same way now in VB.NET I use resource files and man they are great more in vb.net where u get intellisense.
>Very good, Alexandre.
>But it is possible that "reduce memory consumption" means 'reduce the impact on MVCOUNT'.
>It could also be that "increase performance" refers to something totally different than the 'constant' being included in-line *IN* the instruction. For example, maybe it is the case that memvars have to go through the 'is it a field name or a memvar' check before being used whereas 'constants' are in their own separate 'pool' where that is not an issue. In which case it's *possible* that using m. makes memvar usage virtually as fast.
>As for simplifying programs, that's debateable. I've seen Sergey ask (and be correct) a few times 'are you sure you don't have a constant defined with the same name'. And to me hidden things are intrinsically *not* "simplification".
>
>In other words, the statements in Help don't do a whole lot to clarify the situation.
>
>But in the end this is another of those VFP capabilities that comes down to personal taste.
>
>cheers
>>
>>To create a constant with #DEFINE, specify the constant's name with ConstantName and its value with eExpression. When the program is compiled, text substitution is performed and the constant value expression is substituted for the constant name wherever it appears in the program. You can stop the substitution for the constant by issuing #UNDEF.
>>