This application object property provides ability to control general Visual FoxPro language settings. This includes the ability to check for improperly declared memory variables.
_VFP.LanguageOptions [= eValue]
|1||Strict type declaration is required for memory variables.|
When LanguageOptions is set to 1, you must declare all memory variables and arrays as LOCAL or PUBLIC prior to using them. An attempt to use an undeclared variable or array will generate output to the DEBUG OUTPUT window. No error is generated. You can log this output to a file as in the following code:
SET DEBUGOUT TO MyErrorFile
The output from undeclared variables in LanguageOptions is comma-delimited in the following format:
LangOptionsErr, DateTime, cLineNo, cProcedure|cMethod, cFileName, cVarName
|LangOptionsErr||Specifies the name of the output type for searches and filters|
|DateTime||Specifies the time stamp when run (= DATETIME( ))|
|cLineNo||Specifies the line number where error occurred (=LINENO( ))|
|cProcedure|cMethod||Specifies the name of the procedure or method in which the error occurred ( = PROGRAM( ))|
|cFileName||Specifies the name of the file in which the error occurred. (=SYS(16( ))|
|cVarName||Specifies the name of the undeclared variable|
Declaring variables PRIVATE does not create a variable (unlike declaring variables PUBLIC or LOCAL), so the following code generates a log entry:
PRIVATE myvar myvar = 1
Commands that create variables on the fly, such as SCATTER ... NAME, REPORT... NAME and others, will generate log entries, because these variables are created as PRIVATE.
The following code shows the debug output resulting from entering an undeclared variable, RR.
example: vfp.LanguageOptions=1 RR=4 LangOptionsErr,01/23/01 03:02:41 PM,11,TTT,C:\VFP\TEST\TTT.FXP,RR
Strict typing in Visual FoxPro is enforced only at run time, so you must run code to detect errors. Strict typing affects both development and run-time versions of Visual FoxPro.
Note Use of private variables such as those declared with the PRIVATE command or those created using the NAME clause of certain commands will generate errors. If you are distributing code that might be affected by developers potentially setting this property to 1, you should protect your code by resetting this property to 0 when needed.