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.
Regional, #Region
Regional variables were a bizarre scoping technique in FoxPro 2.x. This approach is no longer supported starting in VFP 5.
Usage
#REGION nRegionNumber
REGIONAL RegionalVar1 [, RegionalVar2 [ , ... ] ]
Okay, you’ve got down PUBLIC and PRIVATE variables, right? LOCALS are pretty straightforward. So now there’s nothing left to figure out, right? Wrong. REGIONAL throws a curve ball at the scoping model.
Regional variables were created for FoxPro 2.x screen sets containing snippets from different screens that could contain the same variable names. When a variable conflict was detected, the Screen Generator would issue REGION commands. At compile time, FoxPro modifies the variable names to unique variable names. Each variable is padded to 10 characters with underscores, then the last few characters are replaced with the region number. Each of these newly created variables behaves as a private variable from here on in.
Since variables associated with forms are now properties of the form, the scoping of Form.Property eliminates the need for this method of variable renaming on the fly. We don’t expect we will ever code a REGIONAL command ourselves (we haven’t yet!), and we include the gory details of how REGIONAL works here purely for reference, should the reader need to convert older code. Otherwise, we suggest you stay away from this command.
REGIONAL is out of the range of typical application development. Expect trouble integrating third-party tools into your application if you choose to get into REGIONALs in a big way. Debugging can also be a little more challenging, since these variable names are generated at compile time and don’t exist in your source code.