>>>Well, you see, a lot of the functions have the same name. They just live in different prgs.
>>>
>>>This stems from another topic of debate: I delegate a lot of form-centric processing to a PRG file. User clicks "Apply" button. The click() routine does:

>>>do cmdApply in ThisformsPrgFile with Thisform,andOtherParms...

>>>
>>>What I need is a way to invoke a function in such a PRG file.
>>>
>>>I know there has been some debate about doing things this way. I personally have found it _much_ faster to develop apps when I package form-centric code into a PRG (one PRG for each different SCX file) rather than having to continually/repeatedly manipulate code in the form's events/methods. You can leave the PRG open for editing, tweak it, and not even have to close the form (much less modify it) in order to test your code changes.
>>>
>>>So that's what's behind my original post.
>>
>>Interesting. That sounds to me like the reason for a business object.
>
>Exactly - and a prg based one...
>
>in form's .load()
>
>this.newobject('oBiz','thisformsBiz','thisformsbiz.prg')
>
>and later
>
>thisform.obiz.CmdApply(params)

A disadvantage of that approach is that the class gets locked to the form (unless you tell VFP to remove it from memory), and when you do, the business object becomes unbound from the form. So you have to close the form and re-open it to test any changes in the prg. Most ideal to me, in terms of rapid development, is to not have to close the form, and not have to modify the form, but only tweak the prg (already open in the VFP editor), compile it in place, and let the form's E's and M's call out to the PRG. Once the PRG gets loaded in as a class, a lot of that flexibility disappears.