Consulting

Results 1 to 10 of 10

Thread: A Reminder Re: Module-Level Variables

  1. #1

    Red face 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

  2. #2
    VBAX Expert Imdabaum's Avatar
    Joined
    Jun 2006
    Posts
    652
    Location
    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.
    Someday I'll understand everything...
    Even then...I'll still pretend I'm a beginner.

  3. #3
    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.

  4. #4
    VBAX Expert Imdabaum's Avatar
    Joined
    Jun 2006
    Posts
    652
    Location
    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.
    Someday I'll understand everything...
    Even then...I'll still pretend I'm a beginner.

  5. #5
    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.

  6. #6
    VBAX Expert Imdabaum's Avatar
    Joined
    Jun 2006
    Posts
    652
    Location
    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?
    Someday I'll understand everything...
    Even then...I'll still pretend I'm a beginner.

  7. #7
    VBAX Master CreganTur's Avatar
    Joined
    Jan 2008
    Location
    Greensboro, NC
    Posts
    1,676
    Location
    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.
    -Randy Shea
    I'm a programmer, but I'm also pro-grammar!
    If your issue is resolved, please use Thread Tools to mark your thread as Solved!

    PODA (Professional Office Developers Association) | Certifiable | MOS: Access 2003


  8. #8
    VBAX Expert Imdabaum's Avatar
    Joined
    Jun 2006
    Posts
    652
    Location
    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?
    Someday I'll understand everything...
    Even then...I'll still pretend I'm a beginner.

  9. #9
    VBAX Master CreganTur's Avatar
    Joined
    Jan 2008
    Location
    Greensboro, NC
    Posts
    1,676
    Location
    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.

    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.
    -Randy Shea
    I'm a programmer, but I'm also pro-grammar!
    If your issue is resolved, please use Thread Tools to mark your thread as Solved!

    PODA (Professional Office Developers Association) | Certifiable | MOS: Access 2003


  10. #10
    VBAX Expert Imdabaum's Avatar
    Joined
    Jun 2006
    Posts
    652
    Location
    Sweet.. Thanks Cregan
    Someday I'll understand everything...
    Even then...I'll still pretend I'm a beginner.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •