>>>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.

That works if your framework is easy on the environment - your form doesn't expect too many global objects, there aren't too many dependencies etc, and your form can pretty much run without much foreplay.

I've rarely seen such frameworks. Usually, to be able to run a form, I need to compile (at least into an .app file), for which I have a simple a.prg (for "build and run the app if no errors") or b.prg (build the exe and run it). On today's machines it only takes a second. Logging into the app takes longer :).