>Mike:
>
> The fact is if you already know the name of the routine you want to call.
>
>Quite an assumption on your part. For infrequently used routines, I typically don't.

Notice I said if. However, if you use a procedure library, you'll have to look in each of them for a routine you can't recall the name of? You should name things so they are easily recalled - more easily than the code they contain.

If you rely on a text search, no different again.

>
>>>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.
>>
>>Yes I do. Even with different procedure libraries you are well advised to name each function uniquely. I can open many prgs at once and do the same comparison. In fact with a large prg, if you want to company function 1 at the middle with function 2, nearer the end, you'd do a lot of unnecessary scrolling.
>>
>>The benefits you speak of are really over emphasized. The arbitrary grouping is only confusing to a new developer.
>> What is the benefit of having all dates functions in a single date library? The fact is if you already know the name of the routine you want to call, just call it like calling VFP's own commands. No need to worry about which procedure file is open. It may cause a little slowness at design time, but in the exe - which is really the goal of all of this - it is actually faster since there is no overhead from SET PROCEDURE TO.
>>
>>>
>>>
>>>
>>>>>>1. No need to change PROCEDURE to FUNCTION. You can call either one as a function.
>>>>>
>>>>>Oh, I didn't really plan to change them; was just asking it theoritcally to prove the matter.
>>>>
>>>>Unlike most, I do not use a procedure library at all. That means I never have to say SET PROCEDURE TO nor worry about which one is open. A .prg like this...
>>>>
>>>>myudf.prg
>>>>LPARAMETERS tn1, tc2
>>>>*whatever
>>>>*optional return
>>>>
>>>>can be called by DO myudf with params or MyUDF(params). Lots of typing savings excluding all those PROCEDURE and FUNCTION declarations ;)