Hi Mike,

I noticed by your byline that you were involved with the Toronto FPUG - I went to some of those meetings way back when...not sure when I dropped off - I think I found them easier to go to when I lived in Whitby as Toronto did not seem so big and bad then - now that I am out in Guelph, who wants to venture past Mississauga! When you work 5 minutes from home, going into the big bad TO just seems like too much....I think the last time I went was when the group was meeting at the library at the North York City Centre?

Anyhow, enough reminiscing....I started using procedure files back in FP2.x days and have just not switched from them - I really do not have a lot of them - one for all my general stuff, another for the specific app and that's about it. I think I liked them way back because in prehistoric days, when you were limited to 8.3 names, it allowed me to name longer (whoopee, 10 chars - but I would often tack on a few more to make the name understandable even if only the first 10 were read by FP). And so I stick with old ways - don't think there is any "hit" to having them all in one .prg any more than in dozens of little prgs....

Albert



>Hi Albert
>
>I strongly believe such a functions should be their own .PRG. If naming it is hard, imagine the added difficulty of trying to remember both the name and in what library to find it! Not only that, but you never even need a set procedure to to use it. That seems to me to make it even easier to use!
>
>It certainly should be a name that is explicit for the return value. You call the function for it to return something. You can comment the header of the function with keywords so you can find it again later, whatever you call it.