>So you have a SEPARATE prg file for each Func/Proc?
>
>To me, there is some bene to have them all in one file, or at least grouping certain ones within perhaps a few different .prg files. It makes comparing and reviewing a little quicker since you can scroll up or down withing the file quickly, and Document View is some help also. You don't get that with separate files.

I too use a single file for each function/procedure -- I typically use the notation FUNCTION instead of PROCEDURE. But I go further -- in the file I explicitly define the function and the endfunc lines:

FUNCTION MyFunction
LPARAMETERS tnValue
LOCAL lnReturnValue
***
***
RETURN lnReturnValue
ENDFUNC

If there are specific cases of functions that only this function would use (for repeating blocks of code or simplicity of code) then I include those in the same file as the main function. These are then "local" functions only to this main function. I typically do not use the SET PROCEDURE command; although, I have come across a recent use of SET PROCEDURE to eliminate another error. By doing this, I don't have to worry about name collisions of functions.

In declaring API commands in DECLARE - DLL commands in classes, I have run into a problem of different classes each using the same DLL commands and then each class releasing the DLL commands in their destroy event (this is from the GDI classes on VFPx and other classes that use GDI). This then causes the other class to fail due to the command no longer being defined. What I did was to define a DefineAPI.prg that has each DECLARE - DLL in the file as its own function:

FUNCTION APICommand
LPARAMETERS tnParm
DECLARE LONG APICommand IN user32 LONG tnParm
RETURN APICommand(tnParm)
ENDFUNC

This file is then included in a SET PROCEDURE at the start of the program. Then if a DLL command is released by one class, this will allow the DLL command to be redefined as needed. So this is the only use that I have now for SET PROCEDURE.