Tracking Undeclared Variables with FoxPro

well let’s start by showing you how to track those undeclared variables in a foxpro application, as we all know that we don’t have to declare a variable before use in this wonderful language, but it is good practice to do so.

so today i found the exact use of the ‘_vfp.languageoptions’ property so let me share what i found. well i new this existed since version 7 but never investigated its use till today.

i have a small application that is been developed in my spare time, this program is what i will use to locate the undeclared variables on.

so what does this mean i hear you cry well lets break down the columns:

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

so using this information, you can see that in the initoobj.prg in the class getdata method i have two variables that are not declared with a local or public. these are: lainifile and lcrealnamelikewise you can see the other forms that have undeclared variables.main reason behind these arrays are the fact they are created with the alines function, this creates the variables as private.

(taken from vfp help file)declaring variables private does not create a variable (unlike declaring variables public or local).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.