Walter,


>Sergey,
>
>>My point is, that there is no reason to use macro substitution if code can be written w/o it.
>
>As others have mentoined, performance can be one of them. For example:
>
>

>cEval = "Somefield = SomeValue"
>
>SCAN FOR EVAL(cEVal)
>	.... Do your stuff here ...
>ENDSCAN

>Is never rushmore optimizable en far slower than
>

SCAN FOR &cEval
>	.... Do your stuff here ...
>ENDSCAN

>
>Of course the same applies to all situations where the EVAL is evaluated more than once while a single evaluated macrosubsitition does the same.

I totally agree with you. It's a good example where macro substitution shoul be used. I guess my statement should say: "there is no reason to use macro substitution if code can be written w/o it and it doesn't affect performance".

>Don't forget Macro substitution and EVAL() are cousins, they both require the runtime compiler to operate.

I've to disagree with you on that one. Macro substitution require the runtime compiler because it can include any valid VFP code. EVALUATE() on other hand, can include only expressions so it can be processed by EVALUATE() function itself w/o the runtime compiler.


>I certainly agree that macro's can be (and are beeing) miss-used by lower skilled programmers, but IMO its not that easy to define a general rule about when to use or not to use macro's.

Well said but I still believe that my above statement can be applied when desiding to use or not to use macro substitution.