>>>>>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.
>>>
>>>Are you suggesting not even name the function inside the PRG (if there is only one function inside a PRG)? And just call it by the .PRG name?
>>
>>Its wise to take his advise with a grain of salt. This is not considered good practice and would gain you absolutely nothing. (see my other reply to Mike).
>
>Thank you. My problem has never been the speed, neither compiling no at run-time. Mike assumed I was "after speed."
>The downside - for me - to place each function/procedure in a separate .PRG is a maintenance headache. I have not counted but the application probably has a couple of hundred procedures. And having to scroll through this list in the project manager (if necessary to look at the code of whatever), would increase the time of maintenance. I know many will say that instead of the Functions/Procedures I should have them in classes. And maybe so. But I started this application way before I knew anything about how to build classes. When I can and when it makes sense, I do refactor the code.

There is stuff that is not wise to have in classes. And instantiating odd objects with each and any form just to use a single method is a lot of overhead compared with a procedure. Global classes solve not any problem, because the run in different DATAENVIRONMENTS. Procedures run in the one calling.
The purist OOP-only days are over - if you are happy with your procedures, use it. The only downside I see is that, the visual interface to edit methods is much nicer then scrolling through huge PRG's. (Don't get me started on 32605 lines of FoxBin2PRg.prg ...)