David,

Thanks for all the advice. I'm going to start looking into this asap.

>Colin,
>
>I'd say you are at about the exact right place to start your app class. Put the three apps side by side, pull out the things that are common across all apps, put that functionality in cApp. Where things begin to deviate move that functionality to a subclass of cApp.
>
>I still have UDFs in my apps I don't believe in making something a method just so I can o.DoSomething(). I do not have a SET PROCEDURE file though that holds a whole boatload of functions either. Each one is it's own seperate .prg I have about a dozen of them.
>
>>Thanks for the info David. Just to summarize for my own clarification, one main advantage to an application object is to have one central place for things like:
>>
>>1. Standard setup and cleanup code
>>2. Application object properties instead of global variables
>>3. Custom methods for usage by many apps (Function Library in 2.x terms)
>>4. Application initialization info (i.e. paths/names of files)
>>
>>I'm only working on my third app using VFP5 now, so I'm still in a good position to assess common aspects of each app to possibly start developing an application class. Thanks again.