>>>In pure business applications that
>>>are straight line you probably never
>>>need macros or eval. But generic code
>>>often requires it or you end up with
>>>huge workarounds. This means framework
>>>classes (data handlers, base business
>>>objects, SQL managers etc., dynamic code
>>>execution from code stored in tables/strings
>>>(try that in another language <s>)).
>>>Then there's parsers and tools that need
>>>to dynamically look at data or object figure
>>>out what the type info is and then act on
>>>that. That kind of stuff is next to impossible
>>>if you don't have EVAL().

I definitely agree. I was trying to point out that for an awful lot, even most, of the cases where I see macro expansion used, there are other approaches that work. But there definitely are times when there's no substitute for macro expansion. Nonetheless, this is not such a huge issue, for most apps, as it might seem at first glance. Different languages have different approaches (including FPx.x vs. VFP) -- some overlap, some don't, some are hard or impossible to duplicate in another language, some require different approaches. I suspect most people on the VFP UT believe that VFP is a superior language to most (certainly I do). But, sometimes these posts remind me of a client I have who is still using a five year old copy of Quattro Pro because he likes the function keys, and simply *can not* imagine how anyone can work with a spreadsheet that is any different. That's fine, it's his right, but it is by and large an uneducated opinion, because he has not given the other approaches a chance. And, he might be closing himself out of other features that would be available is he would switch his mindset a little. This was a problem for a lot of FoxPro folks when we started migrating to the OOP world -- "how in the world can you not use public variables?" -- and in the next few years, as Microsoft's (and other companies') tools move into .NET, and wherever else, an open mind seems important. Deciding, for instance, that without macro substitution you cannot replace data in a field, and that therefore you cannot live without macro substition -- that's not a valid argument, and not a mindset I'd be anxious to encourage in my programming teams.