This way you're in a way broadcasting a form wide message to all objects that have 'MessageArrived' property. Only those objects react and they know how to react, not the sender. If they needed to return a value then again different scenarios. Sticking with 'MessageArrived' called objects could in turn check if caller has 'MessageReceived' property or method. One of them could say 'I received your message, done blah blah, placed return values to ...' or checks if caller has 'arrayPlaceRetValsHere' and puts return info there.
This is like drag&drop. Dragged object doesn't know where it's dragged, what object ends the drag and how, what does target do with oSource. The object ending the drag knows oSource and could invoke its methods or set properties if oSource lets it to do.
Cetin

>Cetin,
>
>Thanks for your reply! This seems to be a very flexible method. Will it be right to say that this way of doing it is best suited where the caller doesn't need to know what's going to happen in the receiver or which object that's going to receive the message? What if the caller needs a return value from the receiver; would this change the scenario?
>
>Thanks again!
>
>Jens Erik
>
>
>
>>Jens,
>>Many ways to handle. With VFP6 a simple way might be to use assign :
>>
>>thisform.setall('MessageArrived',uMessage)
>>
>>*Custom method HandleMessage - appears in classes with this functioanlity
>>lparameters tuMessage, tcCallerMethod
>>tcCallerMethod is something like :
>>frmMyForm.myObject.Setall
>>do whatever with tuMessage
>>
>>*MessageArrived - cutom property
>>*MessageArrived_Assign
>>lparameters vValue
>>this.HandleMessage(vValue,program(1))
>>
>>Cetin
>>
>>>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!