>>Either a procedure written in the starting prg or a procedure living in its own file and called by the file name - AFAIR the "linker" resolves those to top levels as well. A procedure of the exe has more opportunities setting procedure files in the app or setting classlibs. Another way to go is to force the exe into the call stack by step loaders - a way of doing things common in 2.x days.
>>
>So if I understand you correctly, my procedure file named "myProcFile" that contains several procedures (like "myProc1", "myProc2", "myProcN") needs to be split up into "N" prg files? or put the contents of "myProcFile" into the main prg?
>
>If that's the case, WOW that's a lot of work for something that the help file does not make clear (to me).

not really - in the project I simplified it took only a copy with a different name of one single file to be included in all apps/exes. In this file were 2 procedures: one to "set proc" to files from that app/exe and one to make sure object references were found to allow finding singular base classes only present in this app. You have to make sure that procedure/function names are cardinal in a running program instance (all exe/Apps!), as vfp will make "faulty calls" to identically named functions - about the only real drawback compared to foxpro[Dos,Win] which showed better behaviour.

HTH

thomas