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.
COMPILE DATABASE
, COMPILE FORM
, COMPILE CLASSLIB
, COMPILE LABEL
, COMPILE REPORT
These are commands you won’t normally need to use. They compile the code stored in a database, form, class library, label or report—an operation that usually happens automatically. However, if you go in and make changes (say, by operating directly on the underlying table), the updated code isn’t compiled. In addition, when you move things back and forth between various versions, they may need to be recompiled (most often when moving from a later version to an earlier version). So these commands let you deal with that kind of situation.
COMPILE DATABASE DBCFileSpec | ?
COMPILE FORM SCXFileSpec | ? [ ALL ]
COMPILE CLASSLIB VCXFileSpec | ?
COMPILE LABEL LBXFileSpec | ?
COMPILE REPORT FRXFileSpec | ?
Databases contain code in stored procedures. Forms and class libraries contain code in methods. Reports and labels have code in the methods of their data environments and band events. All store this compiled code internally in a memo field.
All of these commands let you compile a bunch of whichever object at once by specifying a name, including wildcards.
The VFP 6 docs say that COMPILE DATABASE can handle only one database at a time. Not so, though it was true in earlier versions. The VFP 7 Help gets it right. |
The keyword ALL in COMPILE FORM
says to compile the code for all VFP platforms. If you’re in VFP 5 or later, Windows is all there is, so you’re not likely to use ALL much, except in VFP 3. The newer additions to this group of commands (CLASSLIB, LABEL and REPORT) don’t reject the ALL keyword, but we have no reason to figure out if they actually do anything.
COMPILE FORM can also be used to compile class libraries. While this is a moot point in VFP 5 and later, it's pretty handy in VFP 3, since COMPILE CLASSLIB doesn't exist there. |
A count of the errors found while compiling can be displayed on the status bar. If SET LOGERRORS
is ON, the actual errors are stored in a file of the same name as the object being compiled with an ERR file suffix.
To compile a database, you need to have exclusive access to it. That’s not so bad because you’ll probably want exclusive access for the kinds of changes that lead to compiling it anyway. Interestingly, you can compile a database whether it’s open or closed, as long as you can get exclusive use.
These versions of the COMPILE command don’t offer equivalents to the NODEBUG or ENCRYPT options available in a basic COMPILE. Even compiling forms within a project with these options turned on doesn’t change the object code. Although we have hardly ever used them, this may cause some heartache for folks with security concerns. If you’re shipping a production application and need these features, you’ll need to use the Project Info dialog of the Project Manager.
Compiling is the one thing you can do to a database that doesn’t fire a database event in VFP 7 and later. For some reason, there’s no CompileDatabase event.
USE MyForm.SCX
MODIFY MEMO Methods
* Now change some of the code there and save it.
USE
COMPILE FORM MyForm
Build App, Build DLL, Build EXE, Compile, Create Classlib, Create Database, Create Form, Create Label, Create Report, Database Events, Modify Class, Modify Database, Modify Form, Modify Label, Modify Procedure, Modify Report, Open Database, Set LogErrors