>>>Thank you. So far, the advantage (IMHO) in using the PRG without declaring the FUNCTION is that I don't have to SET PROCEDURE... Calling PRG should always work since it is in the .EXE. Since no one brought up any disadvantage(s) of using PRG without FUNCTION, I will go that route.
>>
>>There's another advantage: if you keep all of them in the same folder, you can't have duplicates, which is easy to do with set procedures. If a duplicate is detected it's actually not detected, the last one in a prg is the one (if in same prg), or the first declared one takes the day (or the last? haven't had that in years). So if you create such duplicate functions, you have just won the ticket to a whole afternoon debugging session.
>>
>>There are limitations, though - while any other filename can contain spaces etc, a prg-as-function has to have a name which conforms with the stricter rules for function names. Also, it has to be on the path, as you can't have a path in a function call. Both attempts here led to errors:
>>
>>? prgs\dcmake3()
>>? "prgs\dcmake3"()
>
>On your point of spaces in the file name, I would never even think of creating a PRG with the space in the name. The only documents/files that I ever create with spaces in the name are Word documents. Pretty much 100% of other files I have created, I use the underscore ("_") if I need to separate words. So this limitation is not significant for me.
>
>I don't quite understand your point about "can't have a path is a function call". Why would I use the folder name in the function call? The function is in the .EXE so I would only call it as
>? dcmake3()

There may be valid reasons to put a few fxp files in a subfolder (distributing an add-on, having a one-time fix script, anything) and if it had to call other such scripts as functions, the location would have to be included in the set("path") or else it wouldn't work - see my example.