Hi David,

>What Fabio proposes is a rather unuseful thing though.
Yes and no - it was not a very good explained example on my part.
I am usually quite happy with the possibilities that containership gives me, even if the concept of talking to other objects via .parent is not always seen positive, as it can lead to [too] tight coupling. But TANSTAAFL works here as well, and I hadn't considered the price of containment to large enough to measure.

>Createobject() objects aren't part of the form containership hierarchy and therefore they do not participate in the event loop, ie you can't interact with them via the mouse or keyboard and they can't be seen.

I was specifically talking about business[rule] objects, which I sometimes "cast" as visual objects during development time to repeatedly start/test business rules, which on normal operation [field validation for example] get called by the business layer. Usually on release the common parentclass of the rule objects is redefined as non-visual class and/or the "behaviour code" of many rule objects for one table is moved into one object for the whole table. So *after* development not only there is no need to interact visually - it is the prefered way of operating <g>. The "business rule container" doesn't need containership, I only have to be able to access each rule with a specific name, although I prefer to be able to iterate over all rules/rule objects as well.

regards

thomas