Just another note, if I "create" the data-objects on the form, they will still need to talk to other objects via the app.object, so enabling this might be more difficult.

Thanks
Kev

>>Hi
>>
>>I have a complex application that I'm working on splitting up a bit, I'm a little way through but wanted to ask a question. My middle-tier has around 25 data-objects so far, all linked to a main application object.
>>
>>Now, what I want to know is if what I'm doing, is a good idea. Rather than create new instances of data-objects on the forms, I call a method in the (middle-tier) application object that returns a reference to the data-object, this way, if the object is updated by one form, it will always be reflected because it is a continuously running single instance.
>>
>>Is this good practice? Or is it better to create objects freshly?
>>
>
>Hi Kevin,
>
>My opinion is that each form should have its own instance of the data object. The first reason is that most of my forms use private datasessions so that forms using the same data do not interfere with each other. Of course, there are cases where one form opens up another form in the same datasession. In that case, you could pass the data object as a parameter if needed:
>

Do MyChildForm with Thisform.oMyDataObject

>
>The second reason is along the same line of thought that public variables are bad. An application object can certainly provide valuable functions and values to the entire application, but I don't think code outside of the app. object should be allowed to make changes to properties on the app. object. I would be difficult to know whether or not another piece code made changes that you weren't expecting, and even harder to debug.