Yes, basically I said exactly same, but note, that not every object can be included to specific container, here the limitation of AddObject is. Using linked CreateObject() allows to overcome this particular limitation.

>Ed,
>
>The only difference between:
>
>this.AddObject( "moName", ... )
>
>and
>
>this.moName = CreateObject( ... )
>
>is that AddObject causes the object to be added to the containership hierarchy. The object's .Parent property will point to the container it is in. And the object is added to the container's Objects/Controls[] collection. This has the added benefit that the object will be automatically removed during the container's destruct. There is no need to code a this.moName = .null. in the container.Destroy() when AddObject() is used.
>
>In the application hierarchy you mention it doesn't matter if AddObject() or CreateObject() is used.
>
>>I want to reconciliate these two points. It's natural reflection to have some kind of application hierarchy, and AddObject looks, first time only :), as better way, i.e. after you Add(object) something to oApp, you can refer it easily throughhout the application as oApp.MyObject1.... Also, using public variables as a way to promote CreateObject as alternative to AddObject, looks not so good, just because public variable is something out of OO world. However, if you instanciate objects linking them to properties of higher-level object (e.g. oApp.MyObject1=CreateObject("MyClass1")) then you can have both advantages: universality of CreateObject and OO application hierarchy.