>PMFJI, but I've been following this thread and wonder if you or any other contributers to the thread can answer this question for me. Aside from it being more OOP, what are the benefits/advantages of having an application object with properties and methods compared to a main.prg with variables and procedures?

For me, it means that I don't generate main.prg and then enhance it with this or that for each app's specifics, and then decide that some of these are generally applicable, and then add them to other apps as I get to them. I simply keep this general stuff in a class, and once I decide something's cool enough to use it in other apps, I simply move the code from subclass I used for one app, to it's parent, used in all apps. That's for inheritance.

The other thing is rather practical - it's the difference in the whereabouts of various snippets. Are they in neat little .prgs (so you have to know their names to use them), or in one big procedure file (so you have to run through its procedure list) or are they methods in the app class (so you have to open it and look at the code there, and have generally longer sausage syntax when you refer to them). This is more a matter of personal preference.

Third, it's the matter of using global vars vs using app object properties. Here, I think, the other is a clear winner - you can organize them hierarchically, into containers, then have them in collections etc - which is far better than having just vars and arrays (and having to know their names :); furthermore, declaring and assigning any number of public vars is a bore, and you're never sure you've done 'em all. App object instantiates all in one shot, and the way the various properties are initialized can be visually checked in the property sheet, which is almost self-documenting. And the initialization of all this is done at compile time, and not at runtime, therefore we gain some speed.

This is just an opinion, or just an attempt to justify my own preferences. Probably there are equally good reasons against.