A Reminder Re: Module-Level Variables

Hey everyone. I just spent an hour troubleshooting an error, until I finally found something I hadn't expected: a local variable was masking a module-level variable. Just in case it helps anyone, I thought I'd share this reminder: if you have a module variable named X, and you declare a local variable named X, any actions in that method will use the local variable. Unlike a real IDE, the VBA tool will give you no warning.

It's almost enough to make me start using m_ prefixes... but not quite. Too ugly ;)

- Jon of All Trades

Correct me if I'm wrong, but if you use Option Explicit declaration at the top of your module, doesn't it restrict those scenarios? Can't say I know for sure, as I try to make my code readable by my replacement.

Sadly, no. I do use Option Explicit, and will not rule out physical violence against any script kiddy that doesn't. But it does not prevent this problem.

lol. There's another wrinkle for my brain. I have always used it, but I can't think of a time when I used the same variable at a functional and global level. Idk.. I'm anal about my variables though. Of course good programming aside, I was under the assumption that I couldn't use the same variables with the Option Explicit so doing the right thing, but maybe not 100% for the right reason. :)

I usually give a prefix to any variable corresponding with it's scope. gb_X for a modular level variable vs an 'X' in a single sub or function.

OK, I gotta ask: why "gb_"? I can see that for global variables, but surely not for private module variables. Gotta tread softly here, don't want to start a flame war about naming conventions.

I hope you're staying dry! I moved down from Clarksville a couple of years ago, so I feel your pain if you're anywhere near the Cumberland.

NOW IT'S ON!! FLAME WARS!!!

jk. You're probably right, there are better naming conventions but I haven't used true global variables much. Most of my variables that are referenced in multiple functions are used within the same module, so I've dubbed them my globals as they cover the whole globe of that module. (digging the whole deep enough?) I should rethink the strategy I'm sure... but up until now nobody has called me on it as not many people analyze my VBA... they just laugh because I'm not in .NET or Java.

I suppose from now on I'll have to start using m_variable for module level variables... or something like that. Sooner or later I'll become an expert and then 2010 will change everything and I'll be a beginner again.
(It hasn't really 2010 is fun. It even allows you customization of the ribbon like the pre 2007 custom toolbars, I think everyone will like it) But I digress. I have no valid excuse for poor naming conventions.
Job security maybe?

You can always create properties to manage access of your module/class level variables- that way you can avoid overwriting by only allowing a Get. Unfortunately you can't create real Constructors to fully protect fields, but it's better than nothing.

So if I wanted, for example, to run open a form through a module function and protect it against people who didn't have a security level 2 in a user table, I could restrict that module from opening the form based on a property in the module?

A Class property allows you to set permission levels for access to field vales in that class. A field is a variable. If you create a property with a private Let and public Get you would call that a Read Only property, because anything that interacts with that class can freely get the value of that variable, but cannot change that variable's value.

Quote:

---

So if I wanted, for example, to run open a form through a module function and protect it against people who didn't have a security level 2 in a user table, I could restrict that module from opening the form based on a property in the module?

---

You could write a Sub in the module or class that compares the user's login name (or some other identifying piece of information) and give or deny access to the form by immedaitely closing the form and displaying a message if they try to open it or by disabling the button that would open that form so they can't click on it.

Sweet.. Thanks Cregan