>Yes, the reason and rationale for all this extra "plumbing" is to allow a more flexible structure. When sibling objects message each other there is a co-dependency established between these two objects. When an object communicates with it's container it allows extended functionality without further binding multiple siblings. Calling container methods and properties is one way of obtaining a loosely coupled structure. Broadcasting an event is another, however VFP is not very good at raising events.
>
>I am sure that after employing this methodology for a while you will find that it enables you to do far more with less re-rigging of the code. I discovered the need for loosley coupled components after doing it the wrong way and causing myself to pour over code in many objects looking for co-references. When using the parent / child type relationship there is only one place to look for functioal code relative to a certain behavior. Tightly coupled objects cause much interdependency and thus a more brittle and fragile structure which will be very difficult to modify and maintain.

Just another thought, this seems to work better for similar objects that require the same operations to be carried out after certain events.

If some of the objects require additional functions to follow say, a save, then would these be placed in the child object or would the parent object check which object is calling, then carry out the necessary work depending on which object called.

I would have, normally, opted for the former.

Thanks
Kev