"Globals" should be environmental-level setting scoped to the session in which the application is running. For example, an application might allow (in your example below) for a user to log in under a different user name without terminating the application. In this case the session is still in scope even though the user isn't. Any items that would be in existence across both users might be scoped to the session as well - for example a DBC wrapper class or something similar.

>>
>>Of course, all of this leads me to conclude that we should be talking about oApp.oGlobals rather than a property array, so that the application object's UI doesn't get clouded with all of the methods related to the globals collection.
>
>I don't see the need for globals in the oApp object? My question would be, what does the global variable hold information about?
>
>User - it should be a property of Users
>Forms - a property of the Form manager object
>
>What about preferences... well, I don't know the over head of loading preferences from the registrry, but if you have that many that are refered to that ofen, you should have a preferences class. Or, the should be properties of the user class.
>
>Bottom line is, the global holds information about something... that sounds like the property of an object to me... if there is no abstract of the object in your ap, perhaps you should create one! A class!
>
>BOb