>>I gotta side with JimN on this. I don't see a problem with either method. It appears to be more an issue of style. Having one or many objects depend on another object could be particularly useful in certain cases...
>
>Matt,
>
>There is a huge design difference between sibling objects beign interdependent and container-contained dependencies.
>
>Siblings are not naturally dependent on each other, while contained object are by nature dependent on their container. Therefore using a design that fosters sibling dependency is introducing a new dependency to the mix, while captializing on the already present dependency between contained objects and their container is not introducing any new dependencies.

OK Jim, I see your point.

I still believe that you can't exclude the possibility that sibling dependency is useful on occaision. And as far as turning control over to the compiler or modifications, I agree. Which is why I don't rely on 'Bring Forward'/'Push Back' to control the initialization sequence. By returning an .F. from the init of an object unless called by a Method (i.e. the Form.Init), I control the initialization order, at least for the objects of concern.

In and of itself, sibling dependency cannot be called a design flaw until you see its implemention.

Matt