>>>>>>>Yes, I used 'public' just to give quick(dirty) idea, and wrote comments that it's 'simplistic' way and oApp property should be used.
>>>>
>>>>I'll study the rest of this email later but what's the oApp property - can I add properties to my application?
>>>
>>>'oApp' is widely used acronym for Application object (some people call it goApp). The idea is to add it in the Main.prg- first app module:
>>>*** some code here (settings)
>>>oApp=createobject('clApp')
>>>*** some code here (start forms)
>>>READ EVENTS
>>>*** some code here (clear environment)
>>>RETURN
>>>
>>>define class clApp as custom
>>> version="1.1"
>>> msgtitle="BMI UPTS"
>>> dbcname="upts"
>>> loginid=0
>>> loginlevel=0
>>> errorind=0
>>> quitflag=.f.
>>> **** and other properties/methods
>>>enddefine
>>
>>Fabulous stuff, Ed - Thanks. I've been feeling that some of my variables which I've had floating around weren't quite right. I'll chuck them in oApp. I've also got it setting up my help file references and _screen settings.
>>
>>Three further questions.
>>1. I have a procedure file, is it better to put the functions held in it into oApp methods and call them specifically or to leave them in the procedure?
>
>Up to you. You can keep both.
>
>>2. I have all my classes in the one class library. Is it better to have oApp in a separate library?
>
>As you see from code, clApp is created programmatically, i.e. it's not part of library. If you will include some extensive procedures then you can decide to use Custom class library.
>
>>3. Should the library(s) be excluded from the .exe or built in. There are likely to be upgrades.
>
>My preference is to include VCXs in Exe.

Thanks. I've decided to create the class in my library and include some custom methods. Feels a bit more tangible, too. This exercise has cleared up quite a few questions which have been rattling around, I appreciate your help. - Sarah