>>>>Hi,
>>>>
>>>>Is there a way to make sure that when you have code:
>>>>

>>>>do ProcedureName.prg
>>>>

>>>>Fires from a program? For example, say the ProcedureName() is in MyPrograms.prg. Just like when you use NEWOBJECT() you specify the library name (VCX) and the class name.
>>>>Is
>>>>

>>>>SET PROCEDURE TO MyPrograms additive
>>>>

>>>>is the only way?
>>>>
>>>>TIA
>>>
>>>Why are you arbitrarily storing multiple procedures/functions in a single .prg? This does not help the compiler. If you build separate .prgs per function the exe will run them faster, than if it has to dig into other files first.
>>
>>I looked a couple of .PRGs created by Rick Strahl (I am using one of his tools in my VFP 9 project). And he put many functions, procedures, and classes in just a couple of .PRG files.
>
>I've been using similar sort of organization in our code that communicates with various types of timeclocks (for Time & Attendance application) -- i've got a base set of PRG libraries for communicating via serial port, and another for TCP/IP (using socket interface). Each type/model of timeclock has it own PRG libraries (which are divided into two levels -- one that handles communication alone without desktop U/I elements, another set that builds upon the other library and handles the desktop U/I). Each of these libraries have been compiled as separate APP/FRX and loaded via SET PROCEDURE by the main program. By breaking down the application into such "modules" also made it easier to update/replace parts as required.

Makes sense.