To Dragan, Tamar, Christian, Viv, Charlie,

Thanks for your ideas sirs and ma'm. Currently, I am using the one global application variable approach. Then, attach the other "service objects" into it.

Am curious about the mention of a speed penalty using an Access method though. I have used this technique quite a bit, and if this is true, I guess we all have to stay away from it?

Dennis


>>Naomi,
>>
>>Thanks for your reply Naomi. Which do you use?
>
>The difference in speed between these is marginal - whether Fox will have to find the variable or the member of the global variable. What matters a lot is the speed of development and the interdependence of these global objects.
>
>Speed of development: it mostly depends on how your mind works. Is it easier for you to remember which member of oApp does this or that, or what's the name of the independent object doing it? Are there other public singleton objects which aren't members of oApp that you may need to call (in which case you need to remember which are separate objects and which are members of oApp)?
>
>I've also seen a mixed approach, where you do oApp.GetHandle(), but oApp's GetHandle method has only one line:
>
>return this.oConn.GetHandle()
>
>i.e. it delegates the calls to its members. It may be some work to write these little calls, but it may be worth it.
>
>The interdependence is a tougher one, but it can bite you whichever way you go. When your app starts up, in which order do you instantiate your global objects, or in which order do you add them to oApp? Also, while they instantiate, do they call oApp.SomeMethod()? oApp variable doesn't have a value until oApp.init() completes, so you can't call any of oApp's methods (except as this.parent.SomeMethod(), but then you can't instantiate such objects as standalone). They may also require help from other global objects (for example, you may require translated strings, so you should call oTran.Translate(this.caption)... or oApp.oTran.Translate(this.caption), but oTran may not exist yet. It can get quite tangled up.
>
>The solution I found to have the fewest problems is to instantiate these global service objects independently, then to add them to oApp as properties. And also to have them use none of the oApp's code while they instantiate. If needed, they can do that later.