Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
LanguageOptions
This rather misnamed property of the _VFP Application Object, added in VFP 7, provides a creative way to check that variables are declared before you use them. We’d have preferred it to be called VariableDeclarations or something a little less generic.
Usage
_VFP.LanguageOptions = nStrictOrLoose
nStrictOrLoose = _VFP.LanguageOptions
|
Parameter |
Value |
Meaning |
|
nStrictOrLoose |
0 |
Ignore missing variable declarations. |
|
1 |
Catch missing variable declarations. |
Traditionally, variable declarations are not required in FoxPro. However, including them is a good programming practice and, in the long run, is likely to save time and result in better code. LanguageOptions gives you a way to catch undeclared variables, without the massive changes that would be necessary to actually require them.
Regardless of the setting of LanguageOptions, no error is triggered when an undeclared variable is found, either at compile-time or runtime. But, when the LanguageOptions property of the _VFP Application Object is set to 1, declaration checking kicks in at runtime in the development environment only. The first time each variable that’s used but not declared is encountered, a message is added to the Debug Output window. We have a pretty good idea why this works only at runtime. As a program runs, a table of variables is constructed. It’s easy when you get to a variable reference at runtime to look and see whether it’s already in the table. Doing this at compile time would require a lot of new logic in the compiler. Understanding this, we also see why it’s optional—for a large program with a lot of variables, all those checks could seriously affect performance.
The message sent to the Debug Output window begins with the string “LangOptionsErr” and tells you when the program was run, the line number containing the undeclared variable (the first time it’s used), the name of the routine and the file, and finally, the name of the variable itself. Note that you get one message per variable, not one message for each time such a variable is used.
Here’s an example:
LangOptionsErr,12/06/01 11:35:12 AM,77,FILECREATED,D:\FOX\TESTCODE\VFP7\FILECREATED.FXP,TRESULT
Because this feature uses the Debug Output window, you either have to open the Debugger before running the code, or use SET DEBUGOUT to send the output to a file. Otherwise, the messages have nowhere to go.
|
Private declarations aren't good enough for this setting; you have to use Local or Public. We're not calling this a bug because of the way we think this feature works (explained above). Private declarations don't actually create variables; they just reserve names. So, there's no entry in the variable table for variable names declared private, and thus they're seen as undeclared. Think of this as a feature, because it finds your private variables for you so you can change them. Since it's better to pass parameters to other routines that use local variables, having a way to find private variables is a good thing. See the PRIVATE command in the reference section for more information. |
We can imagine using this property on a whole application, logging results to a file, perhaps at the same time we create a coverage log to ensure that we’ve tested all the code.
We suspect that Microsoft may have some other intentions for LanguageOptions down the road, hence the less than intuitive name. The text in the Help file is a lot more generic than what the property actually does at this point.