I understand the issues you raised but I think the way my framework has been designed this will not be a big problem. However, I will double check my work before making a final decision on this. I currently practice manual garbage collection in that I ensure that all object references I create I also destroy so I am not too concerned about dangling object references.

My main goal is to avoid the performance hit of walking up the containership heirarchy. My main concern is when the application is run in Web-Connect. I want the application to running quickly.

In the desktop application only one form can be active at a time so I can update the object reference as the forms are activated. On the web side I will only have one high level container active at a time.

Simon

>>At present I have decided to create a property for my application object that will contain a reference to the highest level container for active object.
>
>Are you sure this is a workable solution? It sounds like you're planning to store a single object reference as an app-level property. But how do you maintain this setting? You could easily have many objects in use from many different containerships. How do you ensure that the one you're interested in is the one that is currently stored in the app object?
>
>I don't believe there are any magic shortcuts for this. In once case when this need arose, I added a property to the objects of interest, and used an _access method to walk up the containership looking for the ultimate parent. This presents a dilemma though: either repeat the walk every time you need the reference (thus incurring a performance hit) or store the value in the object property the first time you find it (this creating a garbage-collection issue that you must watch closely).
>
>-- Randy