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(). Trust me - I tried to build some of this stuff in VB and while you can do it if you really try hard it takes so much code that it's not worth it for the amount of code and the resulting performance.

There are lots of things related to this like VFP's ability to discover full type information from objects at runtime, and based on that being able to 'cast' types to variables. CASE statemetns that work with multiple types - all of this is related to the interpreted nature of VFP while running as fast or faster in many cases than a compiled language for typical operation.

+++ Rick ---


>>>This is exactly the type of situation
>>>where people are too quick to use macros.
>>>REPLACE (lcField) WITH lvValue FOR (lcExpression)
>>>works just fine.
>>>Even if this didn't work, there is still SQL,
>>>and with a RUNSQL() function, we wouldn't need macros either.
>
>Agreed 100%. I've been doing an increasing amount of work in the last year in VB, and one of the first questions my VFP friends ask is always "how do you handle not being able to macro-expand?". Well, to begin with, much of the macro-expansion I see in VFP is data-related (fields, conditions, what have you) and working with DAO or ADO you already work with string concatenation. And, the stuff that's not data-related can often be handled with Case statements or other constructs -- not a "cool" solution, I will admit, but it works much of the time. This does leave certain percentage of "$%&!!$%" circumstances, but not as many as people tend to think.
>
>There are an awful lot of developers out there, in many languages, developing many large and robust applications, who do not use macro expansion on anywhere near the level of VFP'ers. As many of us learned when we went from Private "drop-through" variable approaches in 1.x and 2.x to LPARAMETERS, etc., there are many ways of getting the task done. "Losing" private variables did not cost me that much, in the end.