>>I guess I can loop through aMembers for the form, check the first letter, etc.
>You could also check all properties, if they are of type "O".

I would make sure the property is not an object added by composition or .addobject,
so make a double check in the controls-collection. I think this should be done earlier (release)
and call out to a function paasing this as parameter: that way the logic has to be implemented only once.
That would be the simple case<g>.

But that might create a real perf hit if full-featured objects (perhaps including arrays) if you use
many throw-away objects. I think I would go the whole way if I were to implement such a schema:
create a class through which you work any aggregation on other objects. Code the cleanup method *there* and
use bindevent() to bind the cleanup code to only the objects in need of it. You migth add a logging and
automatic setting if you have to retrofit an existing app to find out which objects need their releases bound.
Perhaps addproperty-calls which add an object should be routed through this object, adding the target property
to the collection of bound objects. Needs cooperation in teams to always use this class.

>
>>Do you think it's worth the trouble to make a generic Destroy method or it's better to continue the current practice of modifying each individual form's Destroy method?
>
>As to this desirability, I am not quite sure. But do consider that anything you do at the root of the hierarchy of form classes, you will have to do only once. And, it might help you have less hard-to-find bugs, in this case, a form not releasing, 'cause you forgot to destroy some individual object.

Depends on the error pattern: for long lived objects using many aggregated sub-objects this is a nice addition, but there are still a lot of problems: double references, activeX are pre-dominant. If possible I try to use .addobject - even less code needed<g>

regards

thomas