How scope works?

[StanH]

I am looking for a link to a thorough discussion of scope: From a given place in a vb6 project, what are the situations to make that make various kinds of objects visible and hidden?

[vb6forever]

IMHO you can boil "scope" down to a definition of "what is available, or what you are allowed access to".
In law that would be do you have standing to bring a lawsuit.
In military that would be, have you been vetted to gain access (have the clearances) AND the need to know the information you seek.
In coding, when you are NOT the programmer, did the programmer give you access to his code or some portion of his code. If you are the programmer, do you want to expose (make available) certain functions to other functions you wrote OR do you want to give someone else access to some of your functions. HTH

Elroy followon post gives some good examples. Whether a variable, function, or object, the terms:
Dim, Private, Friend, Public (aka Global), and Static, apply.

[Elroy]

Stan, this is a huge topic, and you may want to limit the "scope" of your question just a bit (pun sort of intended).

If we limit the scope of the question to "within a specific project VBP", then the answer becomes a bit simpler. But, let's further limit the question's scope to "variables". (Excluding things such as modules, libraries, AX components, API declarations, procedures, and other things).

So, there's one category of variables I'll knock out in the beginning ... those implicitly declared variables we get for all forms and also for any class with its VB_PredeclaredID turned on. We don't have to explicitly declare these, and they always have a scope (and lifetime) that's project-wide.

Now, for everything else, I'll divide it into two broad categories, variables declared in BAS modules and variables declared in any other type of module (which are all effectively some type of class module).

BAS modules (variables):

• Declared in header portion with Public - scope and lifetime are project-wide.
• Declared in header with either Private or Dim - scope is module-wide, and lifetime is for as long as project is loaded.
• Declared in procedure with either Private or Dim - scope is limited to procedure, and lifetime is only as long as thread is in the procedure.
• Declared in procedure with Static - scope is limited to procedure, and lifetime is as long as the project is loaded.

Any other module (variables):

• Declared in header portion with Public - scope is project-wide but must be referenced with instantiated object's name. Lifetime is as long as object is instantiated.
• Declared in header portion with Private or Dim - scope is module-wide, and lifetime is as long as object is instantiated.
• Declared in procedure with either Private or Dim - scope is limited to procedure, and lifetime is only as long as thread is in the procedure.
• Declared in procedure with Static - scope is limited to procedure, and lifetime is as long as object is instantiated.

And then there's also the case where the same variable name may be used at two different levels. A VERY bad practice, but it can be done. In these cases, the more locally declared variable will take precedence.

---

And just quickly, I'll add "procedure" declarations:

In BAS module (procedures):

• Declared as Public (or not specified) - these procedures are seen project-wide.
• Declared as Private - these procedures are seen only in the module.
• Declared as Static, this can be combined with the above, and forces all local variables in the procedure to be static (see above).
• Lifetime of all procedures in BAS modules is for the life of the project.

In other modules (procedures):

• Declared as Public - these procedures are seen project-wide (and possibly beyond the project). Object's name must be used to reference.
• Declared as Friend - these procedures are seen as project-wide (but never beyond the project). Object's name must be used to reference.
• Declared as Private (or not specified) - these procedures are seen only in the module.
• Declared as Static, this can be combined with the above, and forces all local variables in the procedure to be static.
• Lifetime of all procedures in non-BAS modules is for as long as the object is instantiated. (Or, stated more precisely, the lifetime of the local static and module-level variables that may be used by the procedure(s) will be for as long as the object is instantiated. The actual code for the procedures will exist in memory prior to instantiation but unreachable until some object for the class is instantiated. Only a single copy of this class code ever exists, although different variables will be used for each instantiation.)

---

Oh yes, Global and Public are synonyms in VB6, used interchangeably, just as are Dim and Private. Personally, I've gotten away from ever saying "Global", but I must confess that I still do use both "Dim" and "Private". "Private" would be the more appropriate term to use.

And that's about it.

[StanH]

Thank you. That has helped me a lot.

[StanH]

(except in the strange case where the more local variable may be declared below where the more widely declared variable is actually used, all possibly in the same procedure).

I don't understand: "possibly in the same procedure."

[wqweto]

I don't understand: "possibly in the same procedure."

It's probably this use-case:

Option Explicit

Public MyVar As Long

Private Sub Form_Load()
    MyVar = 42
    Dim MyVar As Long
    MyVar = 1
End Sub

Private Sub Form_Click()
    MsgBox MyVar
End Sub

Fortunately (or unfortunately) it does not compile with a nonsensical error like "Duplicate declaration in current scope" on Dim MyVar As Long which it is not, there is no second local variable.

Clearly a bug in the compiler which persist even if you change first line in Form_Load to Me.MyVar = 42 i.e. accessing a public property on Me, having nothing to do with local vars yet it still complains about duplicate declaration.

cheers,
</wqw>

[Elroy]

It's probably this use-case:

Option Explicit

Public MyVar As Long

Private Sub Form_Load()
    MyVar = 42
    Dim MyVar As Long
    MyVar = 1
End Sub

Private Sub Form_Click()
    MsgBox MyVar
End Sub

Fortunately (or unfortunately) it does not compile with a nonsensical error like "Duplicate declaration in current scope" on Dim MyVar As Long which it is not, there is no second local variable.

Clearly a bug in the compiler which persist even if you change first line in Form_Load to Me.MyVar = 42 i.e. accessing a public property on Me, having nothing to do with local vars yet it still complains about duplicate declaration.

cheers,
</wqw>

Ahhh, yeah, I didn't test. You can do that in C, but I guess the VB6 compiler doesn't like it (which is probably a good thing). I'll delete that from my post above.

[StanH]

(Or, stated more precisely, the lifetime of the local static and module-level variables that may be used by the procedure(s) will be for as long as the object is instantiated. The actual code for the procedures will exist in memory prior to instantiation but unreachable until some object for the class is instantiated. Only a single copy of this class code ever exists, although different variables will be used for each instantiation.)

I find that very interesting. I thought the command "New" created a copy rather than changing the scope.

[Elroy]

I find that very interesting. I thought the command "New" created a copy rather than changing the scope.

Stan, I'm not sure you completely understand instantiation. First, let's be clear on the distinction between a class and an object. A class is basically a template from which you can create (i.e., instantiate) objects.

So, when you have a class, you can then create an object (and put a reference to it in an object variable). You're creating an "instance" of the class, or, doing "instantiation".

However, you can have object variables that aren't "yet" instantiated, even ones that are declared as early-bound with a class name. To actually instantiate the object to that object variable, you either have to declare it with the New keyword, or use the Set statement (again, with that New keyword).

And basically, instantiation is not a great deal more than "creating a memory space for any/all the variables that are declared within that class". And, we can instantiate more than one object from a single class. When we do that, we are creating separate sets-of-variables for each instantiation.

That's basically it.

There is another minor detail (that we almost never need to worry about). The object isn't exactly instantiated when we "declare with New" or "Set with New". It's actually instantiated the next time we "touch" that object with any code whatsoever. Again, we usually don't have to worry about that, and can just think of it as instantiated as soon as the New keyword is used.

Maybe that'll help.

Another point, the actual instantiation (along with the memory allocated for the variables of the object) will exist so long as the object variable's lifetime exists. However, with objects, it's possible to have multiple references to the same object (multiple object variables pointing to the same object, and this is NOT the same as multiple objects instantiated from the same class). If you have multiple references to an object, the object's variables (and associated memory) will exist so long as there is at least one reference variable with an existing lifetime. Once the last reference (object variable) loses its lifetime, the object is uninstantiated (and whatever variables it has, their memory is unallocated).

This is the most basic explanation of COM objects, which is what we're working with in VB6.

---

Ohh, one more point. The actual code of a class exists prior to the instantiation of any objects from that class. Furthermore, it's "re-entrant" so that only one copy exists in memory, regardless of how many objects are instantiated from that class. It's only space for more object variables that gets created during instantiation. (It's a little more than that, but not much more.)

[gilman]

Ahhh, yeah, I didn't test. You can do that in C, but I guess the VB6 compiler doesn't like it (which is probably a good thing). I'll delete that from my post above.

In VB6 a procedure variable is not declared before the Dim statement, and:

Option Explicit
Private Sub Form_Load()
    MyVar = 42
    Dim MyVar As Long
    MyVar = 1
End Sub

can't compile because MyVar is not declared in 'MyVar = 42' statment.
In:

Option Explicit

Public MyVar As Long

Private Sub Form_Load()
    MyVar = 42
    Dim MyVar As Long
    MyVar = 1
End Sub

MyVar in 'MyVar = 42' statment is declared, is the variable declared in the declarations section of the Form, so 'Dim MyVar As Long' is does not compile with duplicate declaration in this escope error.
if in Load event of the form, you first declared de var, like in:

Option Explicit

Public MyVar As Long

Private Sub Form_Load()
    Dim MyVar As Long
    MyVar = 42
    Me.MyVar = 1
    MsgBox MyVar
End Sub

Private Sub Form_Click()
    MsgBox MyVar
End Sub

compile and MyVar is the variable declared, in the 'Dim MyVar As Long' statment, so 'MyVar = 42' doesn't affect the global variable declared in the 'Public MyVar As Long' statment, to access this variable you must specify with Me.MyVar, but it only works with Public variables.
If we omit the 'Option Explicit' the behavior is similar, with the difference that the variables not explicitly declared are of type variant and of local scope to the method where they are used.

'Option Explicit
'

Private Sub Form_Load()
    MyVar = 1
    MsgBox MyVar
End Sub

Private Sub Form_Click()
    MsgBox MyVar
End Sub

[Elroy]

Gilman,

That's a lot of explanation for something I think we had straight.

And, just as an example, the following is completely legal in C:

#include <stdio.h>

int MyVar;

int main()
{
    
    MyVar = 5;
    printf("%d\n", MyVar);

    int MyVar = 6;
    printf("%d\n", MyVar);


    return 0;
}

But, it's not in VB6 because of a strange way the compiler works.

In the above C code, the module level MyVar and the local MyVar are two completely different variables, with the module level being accessed in the first printf, and the local variable being accessed in the second printf.