>Could you expand a bit on this. I've been using public variables just to make things work, but wondering all the while if I'm reverting to some old habits unnecessarily. BUT, public variables DO make certain things work, you know absolutely that something is exactly equal to something else, regardless of views, forms, control properties, or anything else. Why are they "NEVER" a solution?
>
Allen,

PUBLIC variables are never a solution because they have one quality that is different than private variables, that is they can be seen by routines above the creating one in the calling stack. If a routine at a higher level needs access to that variable then that routine should have created it. It is an issue of encapsulation and external coupling and that is for procedural coding.

For OO coding, essentially everything should be a property of an object no variable should ever be required outside of the method that creates it. Then its scope is the life of the object and it cannot stomp on any similarly named properties of another object because the object reference is used to access the property. For example I can have a property of the FormManager object named oForm that holds an object reference to the currently active form object and I can also have a property of a toolbar named oForm that holds an object reference to the form that the toolbar belongs to. The two properties will never get confused with each other because one of them is FormManager.oForm and the other is ToolBar.oForm.

Whenever I have seen a PUBLIC variable recommended or used it has invariably been one a these situations, Public was not needed and was used because the programmer didn't understand that a privbate would have done what they needed, a situation where the public was needed because the data should have been in a property of an object but the developer didn't understand that or was not sure how to do it, there is actually a bad design problem in that the external coupling of two routines is designed to be very tight, among others.

In my entire carreer I have only seen two situations where the use of a public variable was justifiable. One was in a system I worked on as a consultant where the app had a number of global variables (which can usually be created as Privates in the start up program) and the design called for a generic startup program that would not need editing across multiple system. Because different systems would require different global vars, the design was for a UDF to be called from the startup program to declare the globals. In order for this to work and have the scope of the globals outlive the UDF they had to be public.

The second I use in my own framework. I like to have the command window available while testing my projects. My startup program takes a logical argument that if it is .T. the READ EVENTS is ommitted so control falls back to the command window. Now I have an application object and if that object was stored in a private var then when the startup prg ended so would the app object. So if the parameter is .T. I declare the var name for the app object as PUBLIC so it will survive the startup program.