>>>>And you could probably expand an object reference via &objectname..&propertyname, but again, why, when name expansion is faster and isn't delimiter-sensitive?
>>>
>>>Well, I didn't say it was fast, just that it was possible. But there are instances where the syntax doesn't call for a name, and so a name expression isn't an option, in which case macro expansion is useful and it's nice to know how to do it.
>>
>>If that's the case, then EVAL() is an option.
>
>Sure. In the example I originally gave (to display the contents of a field when the table name and field name are variables) one could write
>

?eval(eval('lcTableName') + '.' + eval('lcFieldName'))

>instead of
>

?&lcTableName..&lcFieldName.

Actually, you could simply say EVAL(ALLTRIM(lcTableName - '.' - lcFieldName))

This is a single eval, and the ALLTRIM and "-" concatenations are only needed to deal with leading and trailing blanks. Without the issue of blanks (which macro evaluation can't handle in any case, since you can't macro expand the result of a function), EVAL(lcTableName + '.' + lcFieldName) works just great.

>
>>There are relatively few times where macro expansion is desirtable, and this particular case, it's simply the wrong thing to use.
>
>I think we both agree that a name expression is a better choice in this particular case. Again, I wasn't trying to defend the use of macro expansion so much as I was simply saying that it is syntactically possible to reference a table.fieldname that way.
>
>BTW, Ed, there are a few people whose posts I always read here on UT, and yours are among them. Thanks for the many and various insights along the way.

Thanks. for the compliment.