Question about Variable scope

jal

Registered User.
Local time
Today, 08:17
Joined
Mar 30, 2007
Messages
1,709
I have a form.

I thought I could put a "global' variable in my form code, right under the "Option Explicit" line, like this:

Private boolVar As Boolean

But when I try to access this variable in any of the subs coded behind that form (for instance in a button-click handler), I get a "variable not defined" error.

Is it necessary to create a module just to make a global variable?

(I mean, global to the form, I don't need scope beyond the form. The whole project is just one form).
 
first of all use Dim not Private (Dim boolVar As Boolean).

second , without going through the hassel of explaining why .. put ur varriable declaration statment above Option Explicit line then add an Option Explicit one above it (now u have 2 of it) , then remove the lower Option Explicit .
 
There are three places to put variables.

1. Inside a class module OR general module subroutine. Scope: Generally local to the subroutine. Depending on activation method, only exists when the subroutine is active.

2. Inside a class module declaration area. Scope: Local to the class module. Depending on activation method, only exists when the associated form/report is open.

3. Inside a general module declaration area, Scope: Depending on the actual declaration syntax, it could be public to VBA code in all modules (class and general). Depending on activation method, could exist for the lifetime of the session.
 
put ur varriable declaration statment above Option Explicit line then add an Option Explicit one above it (now u have 2 of it) , then remove the lower Option Explicit .

This is an interesting procedurenIGHTmAYOR for applying a Form Wide (module) variable. I have never seen this before and I must admit, my curiosity has now gotten the better of me. Perhaps I have been missing something that could save me headaches down the road. Can you please explain why this must be done when declaring a Form Wide Variable.

Much appreciated.

.
 
Have to admit, I've never seen that one either. In the past, all I needed was to Dim my variables below Option Explicit but before the first subroutine declaration.

Now, I HAVE seen some cases where you put the DIMs between Option Explicit and Compare Database.
 
I must confess I'm scratching my head as I don't think I ever recalling dimming any variable outside a procedure; using either private or public to declare a module-wide variable, even for a form/report module.

This is how I remember it:
Code:
Option Compare Database
Option Explicit

Private MyPrivateVariable As Variant

Private Sub MyProcedure()

Dim MyLocalVariable As Variant

End Sub

Of course, I don't have Access in front of me so I can't double check to be sure my memory's not playing tricks on me.
 
without going through the hassel of explaining why ..

heh hassel it is.

after further development on a form (declaration of subs , etc.) General Declaration Section of a form is known to have this bug of shifting codes other than Options to become part of the very next procedure (thus generating the error he was haveing) while users could swear they have wrote it in General Declaration Section and this stuppid technique works like magic avoiding it :)
 
Thank you nIGHTmAYOR for the explanation. Again, this is something I have never encountered but I will definitely keep my eyes open for.

Thanks for sharing that tidbit of information.

.
 
surely the op's idea should have worked - all he did was created a private variable in a forms code module

perhaps there was a problem in the way he referenced it.

---------
i think i am not able to declare user defined types in form modules, and i have to declare these with global scope in a code module
 
>> first of all use Dim not Private (Dim boolVar As Boolean). <<
When Dim is used at the Module level it is virtually identical to Private. Dim can be used at the Module and Procedure level, where as Private can only be used at the Module level.

>> General Declaration Section of a form is known to have this bug of shifting codes other than Options to become part of the very next procedure <<
Can you point a link where this is a documented bug? ... I would love to read up on it! ... Along with your work around, I would think that a decompile of the db would address any symptoms you describe. Also, another question/clarification ... when you mention "codes" are you talking about the compiled p-codes? ... Do you see this while looking at the file in a hex editor? (As I see from a prior post you have done :) ) ... Just trying to learn more about what you seem to have experienced.
 
>> surely the op's idea should have worked - all he did was created a private variable in a forms code module

perhaps there was a problem in the way he referenced it. <<

I am with you Gemma!

It would be good to see the VBA code involved and how the OP was trying to reference the variable ....
 
I think by placing the declaration as Nightmayor suggested he was working round a bug in Access. it should have worked by Night suggested that his way fixed a problem
 
Hello Rabbie ...

>> I think by placing the declaration as Nightmayor suggested he was working round a bug in Access <<

I am was not trying to dispute that (..well I gues I sorta did by agreeing with Gemma ... but the key work is that the op's method *should* have worked! ...) .... but I would sure like more info on the scenarios surrounding that bug! .... I personally have never run into it (as far as I can recall at least) .... or maybe I did get an error, or experienced some other symptom, and just assumed the form was corrupted, then decompiled or did the "SaveAsText" trick ... in order to recover ...
 
Thanks everyone for the input.

That night I finally gave up on trying to make it work. I decided to go another route with no global variable.

After reading your posts, I tried to reproduce the problem at home but was unable. I'll try it again at work. Weird.
 

Users who are viewing this thread

Back
Top Bottom