>One thing where we quite often use macro expansion is when we want to make something data driven. It can be a menu, a list of objects which should appear, or an object factory with the names of the classes to be instantiated stored in a table. You name it - many Foxers are using these things. The mere ability to make things data driven was a good way to get things more easily maintainable, apps more flexible, and life easier in general.
>
>The other thing is the bunch of places where VFP uses eval() internally, i.e. not using a pointer to an object but using a string to store something. Two examples come to mind: all the DynamicThisOrThat properties of a column in a grid - these things are evaluated - and the RemoveObject method, which doesn't use an object reference, it uses the name.
>
>Having left the compiled world long before OOP came about, I really can't figure how these things are done in a compiled language, or in a language which doesn't have an eval() function. I figure that it must use some table of published names (as COM does, specially DCOM - otherwise no scripts could instantiate objects and call their methods, not having pointers to them), but it probably has its limitations. I really have very faint ideas of how it could be done, and none whatsoever of how it is done. If it is done.

I may be missing your point about all this, especially with regard to those column properties. But my first reaction is that VB/VBA uses FUNCTION "string expression" for a lot of commands where VFP uses COMMAND stringwithoutquotes and therefore doesn't need macro expansion or EVAL().

I don't know if there is a way to simulate Dynamic properties in a subform, which is what Access uses for a grid. I think I may have struggled with that problem before. Of course, Access isn't fully compiled either.