I just discovered that the Me keyword cannot access private procedures even when they are inside its own class model.
Take the following code in Class1:
Private Sub Message()
Debug.Print "Some private procedure."
End Sub
Public Sub DoSomething()
Me.Message
End Sub
This code instantiates an instance of the class:
Sub TestClass()
Dim objClass As New Class1
objClass.DoSomething
End Sub
Me.Message
throws compile error "Method or data member not found."
If I change Private Sub Message()
to Public
the procedure works fine. I can also remove the Me keyword from the DoSomething procedure, but I was under the impression that the idea behind the Me keyword is to ensure that multiple instances of Class1 are properly encapsulated.
Why can't the VBA Me keyword access procedures in its own module when they are private? Is it safe to omit the Me keyword and do something like this in a class?
Private Sub Message()
Debug.Print "Some private procedure."
End Sub
Public Sub DoSomething()
Message
End Sub
Thanks!
Update: Thanks for the tips on proper syntax, my code is working. I am still looking for an explanation of why Me can reference private procedures in an instance of it's own module. I couldn't find any good documentation.
Any guess as to why it was designed that way would be pure supposition without talking to the designers. But my own guess is this, the Me keyword returns a reference to the object the code is currently executing in. I would guess rather than create a special case for Me, they found it easier to continue to obey rules of scope for an object. Which is to say object.method can only work on public or friend methods. So Me, is exactly what it says, an instance of an the currently executing object. And since VBA/VB6 doesn't have shared methods, it doesn't really matter if you prefix with Me or not.
But if it makes you feel any better, I find it incredibly obnoxious too.
In COM, there's a difference between the types of object instances and the types of object variables. In particular, the types of object variables behave as interface types. Every type implements at least one interface (itself), but types may implement other interfaces as well. Such ability is used to fake inheritance.
In some frameworks, if class
Foo
has a private memberBar
, then any non-null variable of typeFoo
will hold a reference to some class object which contains that member. The member may not be accessible to any outside code, but it will exist, and can thus be accessed from anywhere within the code forFoo
.Because COM class-variable types behave like interfaces rather than inheritable class types, however, there's no guarantee that a variable of type
Foo
will refer to an object which has any ofFoo
's non-public members. While a compiler could know thatMe
will always refer to the present object, which will be of actual typeFoo
, the fact that the only object upon which a private member ofFoo
could be accessed isMe
means that there's no real reason for the compiler to support dot-based dereferencing of private members.Me is this class object instance. So no one can directly call private subs or functions or access private variables except this class public functions or subs.
You do not need the
Me
keyword to call inside own class.Uses the private class method GroupAttack by using the Call statement
Thats all you need to do ,works like a charm