Wiki Home

VFPSet Procedure

Namespace: WIN_COM_API
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 across 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:

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

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

If this .APP file also has a file UTIL.PRG inside it, it may issue:
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: 2017.12.13 04:55:27 PM )