> My favorite fox person gave me a tip that the AntiPatterns book addressed this same argument, about oApp being not so good OOP practice, and I sort of put the whole issue on the shelf until I can get my hands on that book.

I haven't seen that book yet, but I have seen the argument. I don't think it makes sense to eliminate the application object entirely, after all, everything has to reside somewhere and something needs to provide global services. I think limiting the application object to properties and methods that are truly related to the entire application is a nice happy medium.

On the same subject, I see a lot of developers use properties of the application object simply to eliminate the use of a public variable. While I think this approach is better than using a public variable, it still muddies the interface of the application object. What would you think about having an aGlobals protected property array on the application object? It'd basically be a 2 column array holding description and value. Then you'd have two methods, SetGlobal and GetGlobal to set and retrieve global values? (Of course, you could also have a globals object that gets instantiated elsewhere or that's a member object of the application object itself). This approach allows you to keep all of your globals in one convenient location, yet doesn't bog down the interface of the application object with properties it really doesn't have to be concerned with. Of course, it also gives you the ability to create globals on the fly in code without using PUBLIC, but now that we have AddProperty that point is kind of moot.