My suggestion will be to create a third class to handle the communication between these two objects.

For example, you could create cusEmployeeSchedule class and add to properties to this class (oCusSchedule and oCusEmployee) to point to the two busines classes. This cusEmployeeSchedule will talk to the other business classes, but neither cusSchedule nor cusEmployee will know about the existance of each other.

>It would be interesting to hear some opinions on object references are handled and the pro and cons of different approaches.
>
>Let's say I have a form with a contained business object (cusEmployee). The form also has a PageFrame with several pages. The reason cusEmployee is on the form is that it will be used by object on other pages as well.
>
>In one of the pages there is another business object (cusSchedule) that needs to talk to cusEmployee. How do you handle this; do you send an object reference via a form method to cusSchedule, or does cusSchedule talk to cusEmployee directly. I don't really like the idea of the latter because it's not a good practice to have sibling object having to know about each other, or am I wrong here? Are there other ways of doing this? Could the cusSchedule object send a message to the form, like this: ThisForm.GetEmployeeObjectReference(), that in turn would return an object reference to the cusEmployee? Or should the cusEmployee object be responsible of finding or creating a object reference to cusEmployee by itself?
>
>If cusSchedule gets passed a reference to cusEmployee by the form, do you keep the reference in a property, or do you release the reference as soon as you're finished using it?
>
>I would really appreciate some opinions here, cause I have a (bad) feeling I'm not using the best approach myself and I would like to find I good practice I could stick to.
>Thanks!