A worksheet module is a document module, which is class just like any other, except it inherits (yes, inherits, as in class inheritance!) members from the Worksheet
interface, and being a document module the only way to create an instance of it is through the host application's object model (i.e. ThisWorkbook.Worksheets.Add
is essentially a factory method).
Being a class module, the worksheet object for that module is an instance of, say, the Sheet1
class, which contains whatever members you put into it, plus every member inherited from the Worksheet
interface... including a Range
property.
So the reason why an unqualified Range
call in a worksheet module refers to that sheet, is simply because of the VBA language's scoping rules - given this code:
foo = Range("B12").Value2
If there's a local variable in that scope named Range
, then that's what Range
refers to.
If there's a member in that module named Range
, then that's what Range
refers to.
If there's a global variable in the current project named Range
, then that's what Range
refers to.
If there's a globally-scoped identifier in a referenced project or type library named Range
, then that's what Range
refers to.
You can disambiguate the Range
call by qualifying it with the Me
keyword, which returns a reference to the current object, in this case through the Sheet1
interface (still assuming you're in the code-behind of Sheet1
):
foo = Me.Range("B12").Value2
That code will work against Sheet1
if you're in the code-behind of Sheet1
, and against Sheet2
if you're in the code-behind of Sheet2
, ...and will fail to compile in a standard module.
But the nature and implications of Me
deserve more attention.
About 'Me'
Me
is a reserved name (you can't have a variable by that name) that refers to something that can only exist at run-time in a procedure's scope: the current object. Under the hood, when you make a member call to DoSomething
against a Class1
object, the call goes essentially like this:
Set obj = New Class1
Class1.DoSomething obj
This means DoSomething
looks like this in VBA:
Public Sub DoSomething()
End Sub
But VBA sees it like this:
Public Sub DoSomething(ByVal Me As Class1)
End Sub
That makes Me
an implicit locally-scoped ByVal
parameter of type Class1
, and inside the DoSomething
scope it holds a reference to whatever object the caller is currently using.
That's basically the crux of my Understanding 'Me' (no flowers, no bees) article =)
(relevant language spec)
When you're in a standard module, an unqualified Range
call obeys the exact same scoping rules:
If there's a local variable in that scope named Range
, then that's what Range
refers to.
If there's a member in that module named Range
, then that's what Range
refers to.
If there's a global variable in the current project named Range
, then that's what Range
refers to.
If there's a globally-scoped identifier in a referenced project or type library named Range
, then that's what Range
refers to.
(assuming no shadowing of the Range
identifier is occurring in that module/project)
The globally-scoped identifier in this case can be found in the hidden Global
module: