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.

>Sorry Nancy. I wasn't being facetious. I am always learning new stuff and sometimes I am surprised at what I don't know. I guess I make leaps occasionally and miss the underlying reasons and background for them.
>
>On a base app I use CREATEOBJECT instead of ADDOBJECT and this frees me from relying on a specific type of underlying class. I could use _SCREEN or substitute a top level form or formset as long as I have one public variable that lets me refer to that OBJECT throughout my app. If there is a better approach or a different approach that teaches me new things, I want to KNOW (inquiring minds and all that stuff ;-))). SO I really was curious as to why you took your approach.
>
>Anyway, thanks for your time it has, as usual, been fascinating.
>
>>Because it isn't there??? Seriously, I was just ruminating on the original quandry...
>>
>>>Sorry. Still confused. Why do you need to ADDOBJECT something to a base object? I guess I also don't realize why it would be so important. Please, enlighten away!!