>There is a difference, PUBLIC variables violate all concepts of encapsulation and should be kept to an absolute minimum. They are easily clobbered by code that inadvertantly uses the same var name without declaring the var private. They can stomp all over other apps that call this app as a module, since we don't always have control over the other app.

M$ itself had some trouble with this - remember the spelling checker bug in FPW, which used too many of variables of its own, declaring them some wrong way, and then actually messed with your variables. I remember having read a long description of a workaround. Keeping it clean is not just a matter of purist attitude, it can actually save you a lot of headache.

>The best 3way to handle this global data problem is to create a var in the startup as a private, pass the var name to the subroutine, in the subroutine create an object assigned to that var and use the object's properties to store the values you need. This approach also has the advantage of keeping any code that relates to those values as mehtods of that object.

Now if we're talking VFP6 we could protect these vars (i.e. properties in the object the variable references) by some restrictful assign method, and achieve some security this way, like disabling any changes to the values of it or logging the attempts (error logging or auditing, whatever). In that case I'd have one property in goApp (or any global object) which would be an instance of GlobalVars class. I like that - it's much cleaner.

Though, in some places around the app I may invent some setting which I'd like to remember into a config table, knowing that my startup routine will create a public var for each of the records in this table. I'd accent the _create_, because in the above scenario, it would take adding properties at runtime, which is not (easily?) feasible in VFP5. In 6 it should be easy.

>In the purest sense there can be no public vars in an application, however, often the application object itself is declared as public. If a read events is used even the app object can be private.

Tried that, too, but prefer to have no code waiting in the background. I guess I'll end up having no startup prg, but launch the app from the welcome screen - it will remain alive and serve as goApp until the app quits.