What is the preferred way to define variables?

[Loomis]

Recent forum responses have indicated that it is best to create variable and arrays as properties of a form rather than declarations in a main.prg program. However, when you do this, variables created in one form aren't available in another unless you use the long variable reference (Myform.myvariable). Also, intellisense doesn't recognize variable names across multiple forms. Is the best solution to use formset as a global object containing variable and array properties. Is this the best solution?

 

[mpastore]

I use a class that calls forms with itself as a parameter. The forms can then share memory via the passed class that they have a reference to.

Variables within the class are protected and only accessible via set,get routines.

Mike Pastore

Hats off to (Roy) Harper

 

[Mike Gagnon]

Loomis

Is this the best solution?

Best is what you define as best for you/. Many years ago I started with Public variables all declared in the main program (I got caught too may times with those), and moved on to Local ones, then came VFP3.0 with form properties and form arrays, and the creation of global application custom classes that can hold all the information you need during the whole session. So its pretty much whatever you are more confortable with.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[HarryB]

I have defined a class, (global object "goGV&quot, for my global variables with some standard ones defined in the class. In my main program, I create the object and add properties to the object for the public variables I need.

HTH,

Harry

 

[craigber]

Variables or properties in one form shouldn't be visible in another. One of the caveats of OOP is data hiding.

IMO, you sould never use form sets. They make control of individual forms almost impossible. Many others, including many VFP "gurus" have agreed on this too.

If you need to share values across forms, you may want to consider using properties of a custom application class.

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"

 

[Loomis]

craigber:
Thanks for the advise on formsets. I have a followup question regarding the availability of variables across forms. You advise to use "properties of a custom application class". Could you elaborate. Do you mean to create a class based on custom class, then base on object on that class and add properties that represent variables. If yes, does the object have to be declared PUBLIC early in the application (main.prg).

PS What does IMO mean?

Loomis

 

[Docpro777]

Tastrade (I think) used a custom application (oApp) class as well as a custom environmental class: I think oApp.Init or oApp.do (UDF) called the environmental class to set and reset public variables at the start.

oApp.Cleanup (UDF) may have released them and called the environmental class to reset variables, etc.

Both classes seemed extremely suitable for declaring public variables and environments, password forms, etc. very early; and they kept their bulky mass out of the main.prg

Philip M. Traynor, DPM

http://www.doctorprofessional.com

 

[craigber]

An application class can be based on any base class. I think most people use Custom. Create the class, add properties and methods that you want visible throughout the application and instantiate it in your Main.prg. I would use a PRIVATE variable instead of PUBLIC.

The application class can do all the program startup stuff you would normally do such as setup your own menu, establish the environment (SET TALK, SET DEFAULT, etc).

Variables used in methods should always be declared LOCAL. That way, they are hidden. Much better for data encapsulation.

IMO = In My Opinion

Craig Berntson
MCSD, Visual FoxPro MVP,

http://www.craigberntson.com

Author, CrysDev: A Developer's Guide to Integrating Crystal Reports"