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.
SET PROCEDURE
, SET LIBRARY
, RELEASE PROCEDURE
, RELEASE LIBRARY
, Set(“Procedure”), Set(“Library”)These commands tell FoxPro where to look for procedures and functions used in your code. SET PROCEDURE
refers only to FoxPro routines, while SET LIBRARY
can access both FoxPro code and routines in external libraries.
SET PROCEDURE TO [ FileName1 [, FileName2 [, .. ] ]
[ ADDITIVE ] ]
SET LIBRARY TO [ FileName [ ADDITIVE ] ]
cProcFiles = SET( "PROCEDURE" )
cLibFiles = SET( "LIBRARY" )
Back in the days before the Project Manager, programmers needed a way to tell FoxPro (and FoxBase before it) where to find those well-debugged routines called by various programs in an application. There were two basic solutions to the problem: You could store each routine in a separate PRG file and make sure it was on the FoxPro path, or you could put your common code into a “procedure file” and SET PROCEDURE
TO that file. You could use only one procedure file at a time, so these files were often massive. Like so many other choices in FoxPro, this one became almost a religious issue for many people.
Then along came the Project Manager and the issue was moot. The PM could find all your code and bind it together neatly into an APP or EXE. Procedure files were out in the cold.
Like the phoenix, procedure files were reborn with VFP. With the ADDITIVE clause, plus the need to make class definitions available to the code that depends on them, SET PROCEDURE
once again found its way into lots of applications.
SET LIBRARY
’s story is a little different. When it was first added to FoxPro, its sole purpose was to provide access to external library files built with the Library Construction Kit (PLBs for FoxPro/DOS, FLLs for FoxPro/Windows). But SET LIBRARY
was enhanced as part of the dBASE compatibility campaign in FoxPro 2.6.
In dBASE and now in FoxPro, as well, you can SET LIBRARY
to either an external library or to a procedure file. In fact, using the ADDITIVE clause, you can have both at once—despite the documentation. However, SET LIBRARY
can handle only one procedure file at a time, though you can open multiple external libraries.
Procedure files are searched earlier in the search order than external libraries.
We suggest you stick with SET PROCEDURE
for procedure files, unless you absolutely need the later search of SET LIBRARY
. Then, proceed with caution, but remember that the ability to open a procedure file simultaneously with library files is undocumented and may not work in the future.
One more warning. SET("LIBRARY") tells you about a procedure file opened with SET LIBRARY only if there are no external libraries open. As soon as you SET LIBRARY TO an FLL, you can't find out about a procedure file you SET LIBRARY TO. On the other hand, DISPLAY STATUS lists the procedure file, rather than the external library, as the library file. |
As with so many other SET commands, SETting LIBRARY or PROCEDURE TO without listing a file clears the current setting.
RELEASE PROCEDURE ProcedureFile
RELEASE LIBRARY LibraryFile
These commands let you remove procedure and libraries files from memory. Both insist you provide the path to the file, if it’s not in the current FoxPro search path.
You can't release a procedure file set with SET LIBRARY. When you issue RELEASE LIBRARY with a procedure filename, you get the error "API library not found." Not very helpful, is it? As far as we're concerned, this is just one more reason not to use SET LIBRARY to do SET PROCEDURE's job. |
SET LIBRARY TO HOME()+"FoxTools" && provided with VFP
? WORDS("How many words in this line?") && returns 6, but use
&& GetWordCount() to do this in VFP 7
RELEASE LIBRARY HOME()+"FoxTools"
* Open some programmatic class libraries without closing
* other procedure files.
SET PROCEDURE TO AppClasses, MoreClasses ADDITIVE
Call, CreateObject(), Declare-DLL, FoxTools, Load, NewObject(), Set Path