It turns out, though, that it’s not a great idea to use EVALUATE() in a FOR clause. If you have trouble figuring out what parameter to pass to TYPE(), imagine that you’re passing it to EVALUATE() to be evaluated.)įor example, in the BROWSE above, you could write: BROWSE FOR EVAL(m.cExpression) (Incidentally, TYPE() and EVALUATE() use exactly the same level of indirection. When FoxPro expects an expression, you can use EVALUATE(), which tells FoxPro to evaluate the named variable, and then use the result as part of the command. Which brings us neatly to the next level. So you can’t write something like: BROWSE FOR (m.cExpression)īecause FoxPro expects an expression there, not a name. Indirect reference works only when FoxPro expects a name. For example, if you write: USE (m.cFileName)įoxPro evaluates the variable cFileName and substitutes the name found there in the USE command. Indirect reference lets you put a name in a variable and refer to the variable instead of giving the specific name.

Usage (cName)įirst, perhaps you want to let a user select a report to run, or you’d like to use the same piece of code to open several different tables. There are four levels, which correspond to the four choices. In any case, all four items let you write code when you don’t know exactly what should happen when the code runs. Hmmm, maybe that’s not such a good analogy. Think of () (called “indirect reference” or “name expression”), EVALUATE() (better known as EVAL()), & (macro expansion), and EXECSCRIPT() as the guillotine that performs the execution. Sometimes you need to refer to a file without knowing its name or you need to build an expression or even a series of lines of code and then execute it. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro. An irreverent look at how Visual FoxPro really works.

Foxpro Commands With Example Pdf