>Hi Jim,
>
>I am confused by your statment on the difference between global and public. I looked up in the help and it said:
>
>PUBLIC COMMAND
>Defines global variables or arrays.

John,

The help file is incorrect.

LOCAL: Available to the routine that creates it. Scoped (life time) from creation until the routine that creates it ends (returns). Not visible to any routines called from the creating routine.

PRIVATE: The default scoping for a variable that is not specifically declared as another scope. Available to the routine that creates it and any routines called from that one or called from oen that is called from the creator (lower in the calling stack). Scoped (life time) from creation until the routine that creates it ends (returns).

PUBLIC: Available until it is explicitly released or VFP is quit. The variable outlives its creating routine. Scoped from its creation until it is explicitly released with teh RELEASE command or you quit VFP.

GLOBAL: Therte is no such declaration of variables as global. However, the generally accepted meaning of a global variable is a variable that have a scope that extends to the full application. Private variables created in the startup program are, by nature, globals to the application since the startup program will not end until the application is exited.

The problem with public variables are the following issues.

1) external coupling: If a routine or group of routines requires that a variable be declared public then ther is an external coupling problem within those routines. For example, Prg1 calls Prg2 which creates a public variable that Prg1 will use. Problem, what is prg2 doing creating data for prg1? If you modify prg2 you MUST revisit prg1 to be sure you haven't broken it. Better solution, create a local variable in Prg1 and pass it by reference to prg2 (Pass by reference means that prg2 when operating on the parameter it received is actually changing the variable that was passed in.).

2) Encapsulation: It is desireable to have a rounte contain all of the needed behavior and data for it to function and to enclose that data and function within it self without having any effects on any other routines. Public variables by tehir very nature will stomp all over the memory space of VFP. They can cause strange problems if you happen to simply assign a value to a var.

In OO there is a maxim that says there should never be anything but Local variables. That is, no variable should ever be referenced outside of the method that created it. If there is a need for a vlaue to extend beyond the method that creates it then that value should be stored in a property of an object.

PUBLIC vars are so invasive that you could run your app, which creates a public variable, and then quit the app to the VFP command window and then run a different app and get errors because of the public var the first app created. You can get an error on the PUBLIC declaration line if the var already exists.

There is only one thing that a public var does that private cannot also be used for, that is having the life of the variable extend beyond the end of the routine that created it. Needing a variable to extend beyond the end of the creating routine is a poor design and the problems with the design should be addressed. Using a public variable as a piece of chewing gum to patch a bad design is not a good idea.