>Reading through the recent thread #243690 about macro substitution reminded me of the more general question I have about when to use macro substitution as opposed to using a string valued variable.
>
>Until I started working with VFP, my concept of a macro is that it's a parametrically defined literal that is evaluated at compile time. So the concept of macro values being evaluated at run-time was a little alien to me ... in fact, I had to do some experiments to verify for myself that the substitution really occurs at runtime.
>
>That's all fine. It works the way it works and now I know. But I'm still a little unsure as to the actual rules for when one would use macro substitution and when one would use variable substitution. Although I have a general "feel" for when to use one or the other, I do not know the specific rule that governs usage. For example, I know that:
>

SET EXCLUSIVE $myOffOnStringVariable

>Is correct and that
>

SET EXCLUSIVE myOffOnStringVariable

>will generate an error.
>
>Similarly,
>

myOffOnStringVariable = "ON"

>makes sense while
>

$myOffOnStringVariable = "ON"

>Might make sense (haven't tried it). But sure as hell does something different. (I think it would stick "ON" into the variable whose name is contained in myOffOnStringVariable).
>
>Rather than acting like a macro operator, & seems to be acting more like pointer dereferencing in C.
>
>At any rate, though I have a feel for how and when to use macro substitution, I'm not sure how I'd state the specific rules for how and when to use it and I think there might be some cases where using either a macro or string valued variable would be legal but would produce different results.
>
>Is there a basic rule of thumb to go by?

A basic rule of thumb is "don't use macros if you can use a name expression". A name expression is a string variable or just any expression which evaluates to a string containing a name of a file, printer, server, variable, alias, alias.field, just field, window, menu, popup or... there may be more, but that's the idea.

So, if cName="mytable", there's no need to USE &mytable, you better USE (mytable). This is specifically good with long filenames, when cName="my table with lotsa spaces in its name.dbf" - if you macro substitute that, you will get the macro expanded to

use my table with lotsa spaces in its name.dbf

and it will choke at the third word, not knowing what it is. You may still USE "&cName" - the quotes will do it.

One useful thing for the macros I found was for calling a procedure whose name is in a table, or calculated somehow - like when I calculated interest using several methods, and calling calc01, calc02, calc03 routines, and, you may guess, the table contained "01", "03" and such in the UseMethod field. Then I calculated the factor like this:

lcMeth=table.UseMethod
lnCoeff=calc&lcMeth()

Of course, I had to make damn sure there were no impossible values in the UseMethod field.

HTH