Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Public vs Private?
- Thread starter august
- Start date
ChrisRChamberlain
Programmer
august
PUBLIC creates memory variables, (or arrays), that can be used or modified anywhere within your application, or in other words, globally. The first character "g" identifies the variable as being global.
PUBLIC gcAlias && Create public variable
gcAlias = ALIAS() && Assign value
PRIVATE hides memory variables, (or arrays), previously declared, from the current program. You cannot use PRIVATE to declare a variable or array
PRIVATE gcAlias
gcAlias = ALIAS() && Assign value
This would convert the variable to being private. Once the program/event/method/procedure containing "PRIVATE" has executed, gcAlias reverts to being public, but the value will be .F.
IMHO, avoid PUBLIC variables if possible, and instead use form properties.
Assuming you have added a form property called NewProperty to your form, then you could:-
DO FORM mainform NAME oMain LINKED
To access NewProperty from the form:-
THISFORM.NewProperty = [Hello World]
To access NewProperty elsewhere in your application:-
oMain.NewProperty = [Hello World]
Hope this helps
Chris [sig][/sig]
PUBLIC creates memory variables, (or arrays), that can be used or modified anywhere within your application, or in other words, globally. The first character "g" identifies the variable as being global.
PUBLIC gcAlias && Create public variable
gcAlias = ALIAS() && Assign value
PRIVATE hides memory variables, (or arrays), previously declared, from the current program. You cannot use PRIVATE to declare a variable or array
PRIVATE gcAlias
gcAlias = ALIAS() && Assign value
This would convert the variable to being private. Once the program/event/method/procedure containing "PRIVATE" has executed, gcAlias reverts to being public, but the value will be .F.
IMHO, avoid PUBLIC variables if possible, and instead use form properties.
Assuming you have added a form property called NewProperty to your form, then you could:-
DO FORM mainform NAME oMain LINKED
To access NewProperty from the form:-
THISFORM.NewProperty = [Hello World]
To access NewProperty elsewhere in your application:-
oMain.NewProperty = [Hello World]
Hope this helps
Chris [sig][/sig]
Chris pretty descibed what they mean how they are used but
I try and keep the use of public variables to a minimum. Everyone uses them occasionaly because they are generally a quick solution to some problem. In large systems, public variables tend to be confusing when your debugging or modifing the system later (Your looking at some snippet in a procedure and you have no idea where this variable is coming from or what it's value may be). The more your systems are OOP'd the less you will see a need for Public variables. At least that is the way it is for me.
As for Private (Perhaps I have missed something) I don't think I have ever explicitly declared a variable to be private. Pretty much any variables you declare in procedures, functions, classes, froms, prgs etc are private (I think it's called "Variable Scoping"/)
[sig]<p> Pete<br><a href=mailto:blindpete@mail.com>blindpete@mail.com</a><br><a href= > </a><br>What your mother told you is true! You will go blind! (from moonshine anyway)[/sig]
I try and keep the use of public variables to a minimum. Everyone uses them occasionaly because they are generally a quick solution to some problem. In large systems, public variables tend to be confusing when your debugging or modifing the system later (Your looking at some snippet in a procedure and you have no idea where this variable is coming from or what it's value may be). The more your systems are OOP'd the less you will see a need for Public variables. At least that is the way it is for me.
As for Private (Perhaps I have missed something) I don't think I have ever explicitly declared a variable to be private. Pretty much any variables you declare in procedures, functions, classes, froms, prgs etc are private (I think it's called "Variable Scoping"/)
[sig]<p> Pete<br><a href=mailto:blindpete@mail.com>blindpete@mail.com</a><br><a href= > </a><br>What your mother told you is true! You will go blind! (from moonshine anyway)[/sig]
As for Private (Perhaps I have missed something) I don't think I have ever explicitly declared a variable to be private. Pretty much any variables you declare in procedures, functions, classes, froms, prgs etc are private
Pete, you are correct that, for practical purposes, variables that you create in a method, procedure, etc. act like private memvars, with one difference that may be crucial to an application: the PRIVATE declaration hides memvars that already exist. Examples:
Example 1
cMyVar = "Fred"
do SubRoutine
? cMyVar && returns "Ethel"
procedure SubRoutine
cMyVar = "Ethel"
Example 2
cMyVar = "Fred"
do SubRoutine
? cMyVar && returns "Fred"
procedure SubRoutine
private cMyVar && hides existing cMyVar
cMyVar = "Ethel"
As you can see in the second green example, the child program (SubRoutine) declares the memvar private, thus protecting any value a variable of the same name may have in any parent program.
This can be very important in bullet-proofing and encapsulating your code, and making it more portable. If a memvar name like "lRetVal" is used in many routines in your system, one function that called on another function could get its memvar values changed unintentionally. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
Pete, you are correct that, for practical purposes, variables that you create in a method, procedure, etc. act like private memvars, with one difference that may be crucial to an application: the PRIVATE declaration hides memvars that already exist. Examples:
Example 1
cMyVar = "Fred"
do SubRoutine
? cMyVar && returns "Ethel"
procedure SubRoutine
cMyVar = "Ethel"
Example 2
cMyVar = "Fred"
do SubRoutine
? cMyVar && returns "Fred"
procedure SubRoutine
private cMyVar && hides existing cMyVar
cMyVar = "Ethel"
As you can see in the second green example, the child program (SubRoutine) declares the memvar private, thus protecting any value a variable of the same name may have in any parent program.
This can be very important in bullet-proofing and encapsulating your code, and making it more portable. If a memvar name like "lRetVal" is used in many routines in your system, one function that called on another function could get its memvar values changed unintentionally. [sig]<p>Robert Bradley<br><a href=mailto: > </a><br><a href= - Visual FoxPro Development</a><br> [/sig]
Foxdev wrote:
This can be very important in bullet-proofing and encapsulating your code, and making it more portable.
I see your point clearly. I suppose I have been lucky to date. [sig]<p> Pete<br><a href=mailto:blindpete@mail.com>blindpete@mail.com</a><br><a href= > </a><br>What your mother told you is true! You will go blind! (from moonshine anyway)[/sig]
This can be very important in bullet-proofing and encapsulating your code, and making it more portable.
I see your point clearly. I suppose I have been lucky to date. [sig]<p> Pete<br><a href=mailto:blindpete@mail.com>blindpete@mail.com</a><br><a href= > </a><br>What your mother told you is true! You will go blind! (from moonshine anyway)[/sig]
Private acts pretty much like a Public Var when Declared at the top level anyways 
[sig]<p>John Durbin<br><a href=mailto: john@johndurbin.com> john@johndurbin.com</a><br><a href= </a><br>ICQ #9466492<br>
ICQ VFP ActiveList #73897253[/sig]
[sig]<p>John Durbin<br><a href=mailto: john@johndurbin.com> john@johndurbin.com</a><br><a href= </a><br>ICQ #9466492<br>ICQ VFP ActiveList #73897253[/sig]
- Thread starter
- #9
- Status
