David,

Your business object should not know anything about the UI layer, other than perhaps the type of return value desired (XML, HTML, ADO recordset, VFP cursor, etc). IF your business object is designed to return various formats, that decision should be indicated to the business object by the UI tier during the call into the business object (by setting a property of the business object or passing a parameter indicating the return type needed).

Therefore, your #2 would be the most flexible approach, and would lend itself to distributed / web applications.

>I have an aged debtors object "ageddebt" which, as you would expect, prepares a table of debtors. Sometimes I need a user interface to this process which allows some settings to be changed and a report to be run. So need to co-ordinate the two, but would like some help.
>
>The form needs to access and modify methods and properties of the "ageddebt" object, which means objects on the form are to be bound to properties of "ageddebt".
>
>So what's the best way of instantiating the form and coordinating with the custom class "ageddebt"?
>
>I see two ways...
>1. If I create the form in a method of "agedebt" then how do I reference the "ageddebt" properties from within the form. If I say in a method of "agedebt" :
>oFrm= createform("agedebtform", this)
>then I have the problem that objects in the form are initialised before the init event of the form, so the data binding is problematic.
>
>2. The other way would be to create an "ageddebt" object in the load event of the form...
>thisform.oAD= createobject("ageddebt")
>dodefault
>
>Now each of the form objects can find the ageddebt object.
>So this makes more sense but is the opposite in effect to whatI used to do in FPW2.6 where a program wrapper called the form.
>
>Any comments please...