Colin,

Up until the last month I didn't have an app object. I had worked on few enough VFP apps that a simple main.prg was entirely adequate. Now I have 4 apps simultaneously under development and it's become an issue of code maintenence, when I add a feature to one of the apps I had to go add the code to other couple of apps. In order to get the best reuse from a "stable" code base I moved the code into a class tree.

I have this little app framework started:

cApp - abstract
   VFPScreenApp - apps that run inside the _screen
      Project1App
      Project3App
   TopLevelFormApp - apps that run as a single top-level form
      Project2App

So the actual ProjectNApp subclasses can be nothing more than setting some of the properties.

capp Properties
mcBaseName = None - base name of this application
mcConfigFile = None - name and location of config.fpw
mcDatabase = None - name of the database this app uses
mcFormFile = None - name of the main form for the app, if empty defaults to appname
mcHelpFile = None - name of the help file, if empty defaults to appname.hlp
mcIconFile = None - name of the icon file, if empty defaults to appname.ico
mcMenuFile = None - name of the menu file, if empty defaults to appname.mpr
mcScreenCaption = None - caption to assign VFP _screen

It has methods:

capp.DoForm - launches the mcFormFile form
capp.RestoreHelp - restore the help system
capp.RestoreMenu - restore the VFP menu
capp.RestoreScreen - restore the VFP screen
capp.SetDatabase - sets the database
capp.SetHelp - sets the help file
capp.SetMenu - set the app menu
capp.SetScreen - sets up the VFP screen


>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?