>>>Hi Mike
>>>
>>>I've spent years trying to convince people to not use procedure files. They are usually an arbitrary collection of barely related things. I believe the set procedure command was originally a work around to allow longer procedure names than 8 char file names.
>>>
>>>In your case, having a routine buried in a procedure file is preventing you from executing it the way you want. If you would extract that routine from the procedure file, add it to the project as a separate .prg file and rebuild your exe, you will still be able to execute it in the current exe and you will be able to execute it from an external exe via DO prgname IN exename.
>>>
>>>HTH
>>
>>Back when I was doing stuff in FPD/FPW I'd run across limitation of individual procedure files (IIRC in FPD/FPW the SET PROCEDURE lacked the ADDITIVE clause). The workaround was to "chain" the files where main program calls PROCLIB1 which calls PROCLIB2, which calls PROCLIB3, which then calls a procedure in the main program (granted, this also meant I was losing call levels - so I had to avoid get too deep in procedure/function calls). That allowed me to (in effect) get more than one procedure file. The other bit that I did was to compile each proclib into its own APP file -- this allowed me freedom to replace affected module and not always have to recompile the program each time I'd changed on of the library files. Each proclib had essentially the same sort of structure where parameters were passed in to indicate the "callthrough" chain -- that way I avoided hardcoding aspects of the chain in the individual proclib, and have the main program determine this.
>>
>>In VFP I've got a similar setup, though utilizing the SET PROCEDURE with the ADDITIVE clause (rather than using a "callthrough" chain) with proclibs compiled as separate APPs as before.
>>
>>Of course this might not help the original poster much -- this requires that the original code written in a way to allow for this sort of operation.
>>
>>As explained by others, you need to set up an "interface" to allow one to use DO ... IN ... -- basically "stub" that calls the actual code in separate PRG.
>>
>>LIB1.PRG (main PRG for LIB1.APP))
>>

>>
>>PROCEDURE StubProc1   && "stub" visible to outside
>>    DO PROC1.PRG   && actual code is in PRG
>>
>>PROCEDURE StubProc2   && "stub" visible to outside
>>    DO PROC2.PRG   && actual code is in PRG
>>...
>>

>>
>>the in the calling program we could do:
>>

DO StubProc1 IN LIB1
>>DO StubProc2 IN LIB1
>>

>>
>>A variation on the above is to do something like:
>>in LIB1.PRG (main PRG for LIB1.APP))
>>

>>PARAMETERS cFn,Arg1,Arg2,Arg3,Arg4,Arg5,Arg6
>>
>>EXTERNAL PROCEDURE PROC1,PROC2  ...
>>
>>DO (cFn) WITH Arg1,Arg2,Arg3,Arg4,Arg5
>>

>>
>>and the main program would have something like:
>>

DO Lib1 WITH "Proc1"  && add parameters if required
>>DO Lib2 WITH "Proc2"    && add parameters if required
>>

>
>Why do any of that? You can add all the prgs you want to the exe/app. They will all get called directly without any need of procedure libraries.

Part of the reason was we wanted to avoid having a single monolithic EXE. The program was broken down into separate units that handled specific functionality of the application -- mostly to allow for ability to update and expand when necessary. Most of these were accessed in more standard fashion with DO (someprocname) in (appname). Only a few of the APPs that were somewhat low-level in nature (e.g. communications libraries) were loaded via SET PROCEDURE -- partly because there was a procedure library sort of aspect along with a classlib sort of nature about them -- mainly they provided an interface layer that was more "VFP friendly" (in particular, providing means of packing and unpacking data structures that are passed to certain DLL calls). Of course, having separate modules means the possibility that you could have mismatched components -- thus we made sure that there was some way that main program can query the version information for each APP module.