Results 1 to 3 of 3

Thread: Variables. Dim, Public, Private. When and Why?

  1. #1

    Thread Starter
    Hyperactive Member Al Smith's Avatar
    Join Date
    May 1999
    Marcellus, MI. USA


    I sorta, kinda, think I understand the difference between Dim, Public, and Private variables, but can someone give me a straight-up explanation of when and why to use each?
    Also, What's the difference between declaring a variable in the declaration section of a module vs declaring the variable in a Sub? Is this what they mean by early vs late binding?

  2. #2
    Junior Member
    Join Date
    Oct 1999


    when you declare in a module with 'dim' the variable is only seen by the module. When you declare in a standard code module with 'public' the variable becomes 'global' (i.e. able to be seen by any other code module or form module).
    when you declare a variable, you can do so in the general section. A variable declared in this section can be seen by any sub in that module. A variable declared within a sub can only be seen by that sub.

  3. #3
    Former Admin/Moderator MartinLiss's Avatar
    Join Date
    Sep 1999
    San Jose, CA


    This is from Help:

    Understanding the Scope of Variables

    The scope of a variable defines which parts of your code are aware of its existence. When you declare a variable within a procedure, only code within that procedure can access or change the value of that variable; it has a scope that is local to that procedure. Sometimes, however, you need to use a variable with a broader scope, such as one whose value is available to all the procedures within the same module, or even to all the procedures in your entire application. Visual Basic allows you to specify the scope of a variable when you declare it.

    Scoping Variables
    Depending on how it is declared, a variable is scoped as either a procedure-level (local) or module-level variable.

    Scope Private Public
    Procedure-level Variables are private to the procedure in which they appear. Not applicable. You cannot declare public variables within a procedure.
    Module-level Variables are private to the module in which they appear. Variables are available to all modules.

    Variables Used Within a Procedure
    Procedure-level variables are recognized only in the procedure in which they're declared. These are also known as local variables. You declare them with the Dim or Static keywords. For example:

    Dim intTemp As Integer

    Static intPermanent As Integer

    Values in local variables declared with Static exist the entire time your application is running while variables declared with Dim exist only as long as the procedure is executing.

    Local variables are a good choice for any kind of temporary calculation. For example, you can create a dozen different procedures containing a variable called intTemp. As long as each intTemp is declared as a local variable, each procedure recognizes only its own version of intTemp. Any one procedure can alter the value in its local intTemp without affecting intTemp variables in other procedures.

    Variables Used Within a Module
    By default, a module-level variable is available to all the procedures in that module, but not to code in other modules. You create module-level variables by declaring them with the Private keyword in the Declarations section at the top of the module. For example:

    Private intTemp As Integer

    At the module level, there is no difference between Private and Dim, but Private is preferred because it readily contrasts with Public and makes your code easier to understand.

    Variables Used by All Modules
    To make a module-level variable available to other modules, use the Public keyword to declare the variable. The values in public variables are available to all procedures in your application. Like all module-level variables, public variables are declared in the Declarations section at the top of the module. For example:

    Public intTemp As Integer

    Note You can't declare public variables within a procedure, only within the Declarations section of a module.

    For More Information For additional information about variables, see "Advanced Variable Topics."

    This is also from Help. Late vs. Early binding is something you probably won't need to worry about for a while.

    Early Binding vs. Late Binding
    Visual Basic can use objects more efficiently if it can early bind them. An object can be early bound if you supply a reference to a type library containing the object, and you declare the type of the object:

    Dim X As New MyObject

    Or, equivalently:

    Dim X As MyObject
    Set X = New MyObject

    Early binding enables Visual Basic to do most of the work of resolving the definition of the object at compile time rather than at run time, when it impacts performance. This also allows Visual Basic to check the syntax of properties and methods used with the object and report any errors.

    If Visual Basic cannot bind an object early, it must bind it late. Late binding objects is expensive: At compile time you get no error checking, and each reference at run time requires at least 50% more work by Visual Basic.

    Generally, you should always early bind objects if possible. The only times you should have to declare a variable As Object is if you do not have a type library for the object in question, or you need to be able to pass any kind of object as an argument to a procedure.

    For More Information To learn more about early binding, see "Speeding Object References" in "Programming with Components."


Posting Permissions

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

Click Here to Expand Forum to Full Width