>>The reason I prefer to reference the object, rather than create, is because all object's are children of the middle-tier application object, the reason for this is because the app object needs to reference objects in their current state (ie the current client's details) so if one object needs something from another, it references the app object to request the info from another object, for the current client record, for example.
>>
>>It seems to be easier to let this app object do the object creating, so that it can hold the object for future reference, if I create a new instance of the object, it will effectively be an orphan not connected to the (middle-tier) app object.
>>
>>Does that make sense?
>>
>
>Kevin,
>
>I probably don't understand exactly what you are doing, but it does seem reasonable to me for the application object to act as a mediator for your business objects.
>
>I still have concerns about multiple forms sharing the same object. What happens if Form1 and Form2 are both active and share the same object? Changes on Form1 will be reflected on Form2. Is this what you want? The worst case is if Form2 makes changes to the object, and you executed a method from Form1 expecting different values. Also, what happens if you have two instances of Form1, each looking a different data? (These are not rhetorical questions. Just trying to better understand what you're doing. <g>)

I may think twice about proceeding with this, it's difficult when the app is half-written already, it will need need re-designing as a 3-tier app, otherwise it could turn out nasty.

Thanks for your help.
Kev