Wiki Home

VFPSet Procedure


Namespace: VFP
Tips, Tricks and Gotcha's with VFP's SET PROCEDURE command
See also Visual FoxPro Invocation Stack
SET PROCEDURE is a very useful command for referencing procedure/function libraries. Just put all your really useful little routines into a .PRG file (or several, grouped by whatever makes sense), then SET PROCEDURE TO util.prg, winutil.prg, clsutil.prg, whateverutil.prg and you can reference all of them as though they existed as individual .PRG files.

Whoa! Hold on! How often will the grouping make sense? Worse yet, what happens when the grouping no longer makes sense? Who wants to go through the hastle of reorganizing the grouping? -- Mike Yearwood

Considering long file names in the O/S, why not just make each routine its own little .PRG? Even without long file names, there is benefit to making each its own little .PRG. Remember, there are Fox people who only use the first four letters of commands. 8 character DOS files names is twice as good ;) -- Mike Yearwood

Benefits and detriments of using one or more procedure files versus many .PRG files for utility routines that can be shared accross projects.


However, the VFP File Search Path (looking for which .PRG file the SET PROCEDURE command is referring to) gets a little complicated when you have multiple procedure files by the same name but in different places, or multiple procedure files in .APP files.

Currently I'm still trying to make sense out of this, and so these answers are not yet complete, but here are some of the complications:

The main program (.PRG during testing) issues:
SET PROCEDURE TO UTIL,COMMON

Then calls an addon program's (.APP file) initialization function:
DO Register IN message.app

This function issues some of its own commands:
SET PROCEDURE TO mess.prg ADDITIVE
( this has at times been tried as SET PROCEDURE TO mess.prg IN message.app ADDITIVE )

If this .APP file also has a file UTIL.PRG inside it, it may issue:
SET PROCEDURE TO util.prg ADDITIVE
and this overrides the previous UTIL procedure file (instead of adding to the the search path anything that may be new in this one.)

Also the syntax:
SET PROCEDURE TO filename IN AppFile.APP ADDITIVE does NOT give a compilation error or a runtime error, but it has the result of releasing all the other active SET PROCEDURE files (ie: the ADDITIVE keyword is ignored) and changes the SET PROCEDURE setting to "filename.fxp" and DOES NOT PROVIDE ACCESS TO ANY ROUTINES IN THE FILE (either the filename.fxp outside the .APP or the filename.fxp inside the .APP).
What about OOP?
It might be instructive to consider creating a custom object (or session object) with mulitple methods as a third alternative. The object (perhaps named udf) would be created in your main.prg and be accessed thereafter. A useage example would be udf.myerrormethod(). Here are some pros and cons I have thought of:
-- Ben Creighton
Contributors: wgcs, Mike Yearwood, Ben Creighton
Category VFP Commands Category Performance
Category Needs Refactoring
( Topic last updated: 2014.09.24 11:42:03 AM )