>>>>>I've seen it used a LOT in building up SELECT statements, if you have a form that has various check boxes and selections etc., then the validation will build up the WHERE clause to include in a single statement.
>>>>>
>>>>>SELECT * FROM myTable;
>>>>>&lcWhereClause
>>>>>
>>>>>Kev
>>>>
>>>>
>>>>Ok, Ok, Ok. I should have excluded SQL statements. I use it for this too, just because we don't have a choice. Notice however that VB programmers don't need macro substitution to run ad-hoc SQL statements, because they have avenues for submitting SQL as a string. I've been lobbying for a VFP equivalent for some time now.
>>>
>>>I used macro substitution and eval statements for a VFP 6.0 application I designed that uses a data-driven rules engine.
>>
>>EVAL is valuable, I agree. Macros, I'm not so sure about.
>
>There are some situations that you dont know a variable name until runtime (for instanse it comes in my mind a form that i am putting verious controls in runtime based on some contitions which somehow prohibit to use an array to hold the control references ...)":
>var="myvar"+ (a string made by some contitions)
>&var="string" && or an object
>?&var (gives "string")
>Is there possible to do the above code by other means ???
>

Why would you not know the name of a variable?

As for objects that you need to construct their name at runtime, there's EVAL().

o = EVAL("THISFORM." + lcObjectName)