Weening a global junkie

[VBAhole22]

I am writing because I need help. I am addicted to global variables. They litter my programming and I know they are bad but I can't avoid them. I need help to break free.
What I typically wind up having is a module with global declarations up top and then a sub below that I usually call InitializeVariables that sets the value of the globals (usually strings with paths to other data). Then in any other procedure that uses one of these globals I have to start by calling InitializeVariable to make sure the global is set.
I am sure this is bad form. I just can't find a better solution.
Is there any hope for a global junkie?

 

[FoFa]

If you are not setting the global variables at startup, than it should not be a global. That at least is a good rule of thumb. How ever there are exceptions. Typically even in a middlin complexe application I have no more than 4 or 5 global variables, and 2 are usually for security. Explain what some of yours are used for and we can see if there are viable alternatives.

 

[VBAhole22]

Well, one way I have used them in the past has been to indicate switch conditions on a form. Like say the form has a check box that says something like, 'do you want to see the sql of the query?' I take the value of that box, load it into a global. So that when I call some subroutine to do something, it check on the global and if it is in a certain state then it sends the sql ouput to a text box on the form. Maybe this isn't he best example I have come across. But a global variable could get this done.
I have been told by others that you shouldn't have subroutines that rely on things that can't be passed in as parameters, like globals. But, I ask, what if you need a routine that sets 3 or 4 variables based on some condition. How would a function return these 3 or 4 variables when they can only return one? My solution in this case would be to use a sub to SET the 4 variables as globals, then I can access them in later procedures.

 

[WayneRyan]

Functions can return Variants (which can be arrays).

This thread has an example:

http://www.access-programmers.co.uk...s=&threadid=7167&highlight=variants+and+array

Wayne

 

[RichMorrison]

This sounds like several sub-issues.

First, I think it is better to use "property" procedures and private variables than to use global variables. Versions of Access from 97 on up support Property procedures. Put the private variables and procedures into one module.

Second, what is need for an initialization routine ? If variables contain "strings to paths" or other non-changing data then it is better to use Constants. If not then just set a default value (blank, zero, etc) in the Dim statement.

Third, global/properties versus passed parameters, depends on the interface. If you need to set a value in code and use that value in a query, then you want a property procedure. Similar situations are setting a value in form code and opening a report with "report" code or setting a value in one form that will be used in the code of another form. For code-to-code interface, parameters are better.

Finally, how many globals are too many ? That's subjective. I have made some apps with lots of property procedures, often for reporting apps that use forms to collect criteria to pass to queries behind reports.

HTH,
RichM

 

[Mile-O]

Also, when passing parameters to functions, you should investigate the difference between ByVal and ByRef.

 

[Pat Hartman]

But, I ask, what if you need a routine that sets 3 or 4 variables based on some condition. How would a function return these 3 or 4 variables when they can only return one?

You are confusing the functions arguments with its return value. A function may return only a single value (in newer versions of Access, that value can be an array), but it may take many arguments.

Public Function MyFunc(argument1 as date, argument2 as long, argument3 as boolean) As Boolean
.....
End Function

So, MyFunc takes 3 arguments of different types and returns a boolean.

 

[FoFa]

I always thought the "global variables are bad" was pretty much hype, until I had to take over a program from a newbie developer. Everything was a global, hard to follow the code because of the variables. I find references to columns or form fields easier to follow usually. I just don't know where the cut off is between memory usage and performance. Might even be a moot point any more with the power of todays PC's. Typically I use globals for capturing the network ID of a user (In an initialization module RichMorris), and also for an ErrorFlag to pass error conditions between modules without redefining it every time. I only think there is an issue when the code gets too messy to deal with. I also believe in many comments through out the code also. Some thing else I do is I usually have a parameters table that stores user/application parameters, and I will assign these to globals as I find this is better than constant access to the table (also in an initialization routine RichMorris). But that's just my 2 cents worth.

 

[CJBIRKIN]

Hi

Just happen to be passing through and saw this, For my 2 pence worth i used to have the same problem. My solution was pretty standard. My understanding of the problem is not that global variables are necessarily evil it's just that over use -like the goto statement- can cause programming to become like spaghetti very hard to untangle without getting in a mess. The key is proper control of access to the variable.


In a module (not the form module create a new one)...


option explicit
dim Iamavariable as string' or what ever

public function setglobalvar(VarValue as string)
Iamavariable = VarValue
end function

public function getglobalVar()as string
getglobalVar = Iamavariable
end function


The get and set functions act like gateways.

As the Iamavariable variable is only dim not public it is only available to functions/subs in the module. The set function is public and can therefore be called from any other module. It is the only way to set the variable.
Like wise the get function is the only way to retrieve the value.

If you are writting tons of code there is always the danger of calling a variable accidently or forgetting after the 20th reworking of your code that the thing even existed (note the "i've been here before" tone ). This can cause no end of problems if your an idiot like me and forget to use option explicit.

As i say "Global" variables are not evil you should just be careful how you use them.


Chris