>The issue is not what the var is or what it does. It is that PUBLIC variables are bad news. They exist beyond the routine that creates them, they can cause conflicts far removed from their use (accidentally using a var with the same name). They continue to exist beyond the application ending (if you are running in the developers version of VFP.

But so do the global objects, whose properties replace them. The danger of an accidental local/private var tampering with it is nil, but this global object's methods are avalilable everywhere around the app. Any nasty routine can approach it and either mess with its properties, or call its methods to do the same. So, globar vars are bad news, for sure, but we got to beware of global object abuse as well. Still, these are easier to find... well, it would be, if we had the Filer the way it was.

>There is only one thing that requires a public var, thast is that the var must be visible to some routine at a higher level in teh calling stack.

I'd call such a situation bad design. Why would a routine have to check for existence of a variable? It should create it and check its value, when needed. With FP2.x we did have situations like that, when some unpredictable vars had to be created in a subroutine and then used in another subroutine - we had to go public then. But, with VFP, we can always pass an object and have its properties filled up with whatever necessary in any routine downstream. There are, surely, other ways to avoid this.