>>I'm wondering what the pros/cons are in using Proc files for UDF's vs. creating Proc Classes to implement UDF's. I've grown accustomed to seeing most VFP developers use Proc files, but in an effort to try to be more 'object' minded I'm wondering if creating proc classes would do the job (perhaps better)? Any insight would be appreciated. Thanks in advance.
>
>Jim,
>
>The rule of thumb that I follow is that if the UDF is an extension of the underlying language then I make it a PRG of its own (I hate proc files becasue they make you include everything in them even if you don't need it), otherwise there should be an object with the responsibility for that behavior. I don't make objects that just hold procedures in their methods.
>
>For example if I create a UDF that formats a city line for an address, well that I would probably put in a PRG. But if I have code that calculates the customer balance from the transactions, that I put in a customer class so that the customer object is responsible for its own calculations.

Seperate prgs huh? Gotta love it when the simple (but effective) is not so obvious. I'm with you on the issue of having to carry around a lot of baggage porting proc files from one app to another when most of the functionality is not needed. I'm going to go to your model for my own development. One disadvantage though would be administration on a large system with a larger development team. Unless you're working with folks who document and administrate well, it would be a nightmare trying to keep track of prg functionality and which ones ship with what app. It definitely wouldn't work in the shop I'm in (sad to say). Thanks for the tip. You just changed the way I think about prgs.