Global variables (1 Viewer)

[deejay_totoro]

Hello,

I have question about global variables - well I think thats what it is!

I am familiar with (private?) variables in functions. But what I would like to do is set up a few "global" variables that would be available to any module/function/form/query within my database.

The variables are actually things like common folder locations which are referred to throughout many modules and things such as exchange rates.

I dont know what to set this up.

Can anyone help?

Cheers!

dj_Totoro

 

[boblarson]

First - global variables are now known as PUBLIC variables.

Second - to declare them for use without your program, put them in the General Declarations Section of a Standard module (not form module).

 

[boblarson]

First - global variables are now known as PUBLIC variables.

Second - to declare them for use without your program, put them in the General Declarations Section of a Standard module (not form module).

Also, you can set constants in your general declarations section of the standard module as well.

So, like

Public blnFlag As Boolean
Const dblExchange As Double = 3.45
Const strMyString As String = "C:\Temp"

 

[Moniker]

Second - to declare them for use without your program,

Bob, I think you mean throughout, not without. That is a tad confusing otherwise.

 

[Banana]

Bob,

I'm pretty sure you can declare public variables in any general declarations for any form, class modules and standard modules.

The only thing you can't declare in general declaration is public constants (private constants are okay) in class modules or forms (which are just class modules), but that can be sidestepped with a Public Enum type.

 

[boblarson]

Bob, I think you mean throughout, not without. That is a tad confusing otherwise.

Throughout, without - I'd prefer without the program as it is less trouble that way.

As for the Public variables - I guess I didn't realize that you could declare public variables within form modules. I've always done it in standard modules (which might make it easier to find them). So, we learn something new again...

 

[pbaldy]

I'm pretty sure you can declare public variables in any general declarations for any form, class modules and standard modules.

If you mean a variable that can be accessed from other forms, I think I'm going to disagree. You can probably use them, but you'd have to fully qualify the name, so what's the use? IOW, with this in one form's general declarations:

Public strTest As String

this won't work from another form:

MsgBox strTest

but this will:

MsgBox Forms!OtherFormName.strTest

As Bob mentioned, I think it's easier to have them in one place anyway.

 

[Banana]

Ahh, yes, you're right. I didn't realize that either.

I do agree with Bob and you that it's easier to declare public variables within a module than a form; it just happened that I had declared public variables in a form before, thinking public meant available to any procedure within a module but I was wrong back then and now know better.

 

[The_Doc_Man]

If the form is not open, it matters not whether it is public or private. A variable in a class module does not even exist unless the form or report is open. So do this in a general module. End of discussion.

to any module/function/form/query

Next issue. There have been nearly a gazillion posts on the subject of breaking the module/query barrier. 'tain't as easy as it looks because the two don't exist in the same domain. Variables exist in memory in your workspace. Queries work with things in records nominally on the disk.

Usually, in order to get a module-based variable in a query, you have to write a public function that returns a value. But the catch is that its argument usually cannot be the variable's name because Access doesn't have a collection of variables that you can easily touch from a query. No easy syntax for it.

Search this forum for posts on global variables. It's a mine field. Not that you can't do it, but it is damned harder than it might first appear.

 

[Banana]

If the form is not open, it matters not whether it is public or private. A variable in a class module does not even exist unless the form or report is open. So do this in a general module. End of discussion.

At risk of making a very bad move of disagreeing with a guy who has been twiddling bits long before I was conceived in my mother's womb, I want to point out a little exception.

Using Public Enum in any class module (I'm not going to say form module because as pbaldy has shown, they behave somehow differently, even though they're supposed to be a class module... so says the paper. So I'm not going there.) allows the constants defined within to be accessed anywhere in the project.

Technically speaking, Public Enum isn't a part of the class module, even if it is declared within the general declaration of class module, and therefore does not require that the class be instantiated.

But that's an exception to the rule; I'd much rather that everyone use a standard module to hold all constants among other thing that should be accessible from anywhere.

 

[The_Doc_Man]

I'm not sure why such an exception exists either, but if you've tried it and it works, maybe you can get away with it.

But you used exactly the right words for other variable types. If the class is not instantiated, it just AIN'T. And nothing inside of it exists, either.

I have used Enum types many times in many languages but it has been a long time since I've done that in Access. Refresh me: Is the public declaration of the enum to which you referred the definition of the enum sub-class or an actual storage declaration of some variable of class enum? If the former, it is meta-data and you are quite right, in that case it does not belong to the class module.

 

[Banana]

I'm afraid I'm not quite sure what you are asking me; I can say no it's not a subclass; it exists in the class's general declaration. For example, my error handling class uses public enum as thus:

Option Compare Database
Option Explicit

'Some private variables

Public Enum ErrorResponse
      ErrContinue
      ErrRetry 
      ErrExit
      ErrQuit
End Enum

and in all over my codes, I use the constants, and even could use it to do something without invoking the error handling.

The article where I got this information says that it's not a part of class module, but doesn't goes into details. I'll find the link when I go to work.

 

[modest]

There are essentially three kinds of modules: class, standard, and object

Class is where your class definitions go
Standard is where your commonly used functions should go
Object is where functions pertaining to a particular form/report are (it is where the event handling goes)

When using global variables, it is advised to declare them in a Standard module, but initialize it in the opening form of the database. If a public variable is declared within an object module, it is only global between controls of that object.

For instance, a global sum (Public lngSUM as Long) declared in a form's module, can only be used between text/list/combo boxes (and other controls) on that form, however another form would not be able recognize this variable. If lngSUM was declared in a standard module, all forms would be able to access its value - it would be a truely global variable.

Another way to use global variables is to store data in a table. This is good for storing user settings/preferences for when the database loads.

 

[pbaldy]

For instance, a global sum (Public lngSUM as Long) declared in a form's module, can only be used between text/list/combo boxes (and other controls) on that form, however another form would not be able recognize this variable.

I think I'll disagree with this. As I noted above, you would have to use a fully qualified address, but you could get at the value from another form. That's not to say I'd recommend the practice; I wouldn't. I'm just saying it can be done.

 

[Banana]

Just out of curiosity, I made two public variables of same name but a different data type, one in a standard module and another in a form module.

I was totally disappointed when the VBE complied without complaining of ambiguous references. It does seem that form/report module is somehow insulated from the rest of modules. I would get thrown a error about ambiguous name had I put the second variable in another standard module.

The more I think about it, the more I'm starting to question the reference books calling form/report a class module... :\