>So when is a var required to be public?

Only when its real scope is over the entire application.

>>As for your example: if you initialize oObj somewhere in a method but it should be available from everywhere, your code will use a lot of IF TYPE("oObj") etc because you have to test it everytime you want to use it. This looks like a design problem. Anyway, even if oObj is a PUBLIC var, then it's better to declare it as PUBLIC at the main prg level and pass it by reference to the method that initializes it. Doing so, you have the felxibility to change your code and to do it more safe and easier.
>
>It is never necessary to declare a variable public in the main start up prg of an app. A private is globally visible to the entire application.

... I don't understand what you want to say here. Sorry.

>I have only one public declaration in my systems. That is a debugging feature of my framework. I can run my application in VFP without a READ EVENTS so I can use the command window, debugger, and editors to work on the app while it is running.

Yes, I know that one can have only one public variable that holds every other public variable. I like this approach mainly because it offers flexibility for code maintenance.

Still, this doesn't mean it's the only valid/good approach/solution. I've seen applications (not only VFP) that have a limited number of public variables and there's nothing wrong with them as long as there's a good design behind it.

My point here is that no rule is absolute and no solution is the only one. As for any other rule, there are exceptions and there are alternatives.

Vlad