>>>Others have given solutions on how to write it without macro substitution. So, it's possible. But IMO macro substitution is a very legitimate technique.
>>
>>Yes it's legitimate technique in places where it cannot be done w/o macro substitution. Using macro substitution makes code slower, harder to read and maintain.
>
>Sergey / Jos,
>
>There are more than enough situations where speed isn't an issue at all, for example if it's not in a million times loop. Even in a SQL-query it's okay, as the substitution is done only once by vfp.
>
>Harder to read? Which one is harder to read? I can't see an essential difference.
>

>&lcString = &lcDir
>STORE EVALUATE(lcDir) TO (lcString)
>

>
>Maintenance issue? Tell me...
>
>The core point is that AndersH may have (had) a feeling that macro substitution is not a proper programming technique. Statements about performance penalties have been abundant in the last decade and still have their impact on many programmers. I challenge those judgments and think that they're obsolete.

Peter,
I strongly agree. (Actually thought to note what you said at the end of my first msg but pressed send early:)
Documents say macro substitution is slower and it's but not enough slower unless used in kilothousands of loops.
Readability and maintanence are kind of programmer styles and what's hard to me might be easy to someone else.
OTOH especially in Turkish forum I tell users to avoid macro substitution. My saying is not based on performance but to hard to catch coding errors they might do like having a space in a filename. Another reason in order to use macro substitution generally you need to create an unneeded variable first (see my first reply for what I mean - I don't need lcDir and lcString in the first place). If I already have the variables for some reason I feel myself free in order to use either macro substitution or eval(),() as I see fit.
Cetin