Me/Self and When You Should Use Them

One thing that I see tripping people up (myself included some days!) is what the difference is between Me and Self when writing REALbasic code. At first glance, they seem to be the same thing -- but they're really not the same all the time. Don't fall into this trap!

Let's start off with an example of where Me and Self can be different. If you've got a button named PushButton1 and it lives on a window named Window1, and the button has been clicked on... Then when the button's Action event is called, there's an implicit parameter passed into the event called Self which represents what window owns it. However, the button has its own instance, and you may need to know what that is. For this reason, there's also a Me parameter that references the actual instance of the control. Ok, let's clarify this a bit. In this case: Me = Window1.PushButton1 and Self = Window1.

Me and Self have a definitive rule for you to follow. If you are in event code that is being called from a window, then Me is the implicit instance of the class being called (such as PushButton, Timer or TCPSocket) and Self is the implicit instance of the owning class (such as Window1). If your event code is not being called from the window, then Me = Self. An example of the former would be the PushButton on a Window scenario. The latter would be a Timer subclass on a Window with the Action event implemented in the subclass itself (not in the window). Think of Self as the owning class instance and Me as the helper variable that can point to any number of things.

The easiest way to understand when Me and Self will be different is to not think about it too hard. If you are editing source code in an editor that says Window1 Source Code (or something to that effect) in the titlebar, then you are editing an event where Me and Self are going to be different. However, if you are not editing source code for the Window, then you are in a situation where Me and Self are the same.

So, when should use use Me vs Self? The best rule of thumb to follow is: only when you need to! If you are editing code that's not in an event, or isn't being edited in the window's source code and you absolutely have to use a modifier to refer to a class property/method/etc -- then you should always be using Self because Self always points to the instance of the current class. However, if you're editing event code for a class dragged onto a window, then you should use caution. I find that if I need to modify the window itself (for example, to change it's title or something), then I'll use Self just so I can have access to the proper window instance (since, if you recall, the window is the owning class). Otherwise, I don't use any modifier at all. The only exception to the "don't use modifiers" rule is when the class and the owner happen to have a property or method with the same name. In that case, if I need to refer to the class instance and not the owner instance, I'll use Me. This is because you have to -- Self is implied, so without Me, you have no way of getting to the class instance variable. Here's an example:

Let's say you have a PushButton subclass with a property called Test as Integer. You drag an instance of this subclass onto a Window which also has Test as Integer as a property. When you are inside of the subclass' Action event you do the following:
[rbcode]
Sub Window1.CustomPushButton1.Action()
Test = 12
MsgBox Str( me.Test )
MsgBox Str( self.Test )
End Sub
[/rbcode]
In this case, what you're doing is setting Self.Test = 12; Me.Test stays at its same value. So if you need to refer to the PushButton subclass' Test property, you must explicitly say Me.Test.

The one last thing I hope you take away from this little blurb is that you should never, ever, ever use the name of the object directly when wondering whether you should use Me or Self. You'll notice that I do not ever suggest saying Window1 in place of Self or Window1.PushButton1 in place of Me. This is because referring to windows by name causes bad mojo. It's called implicit instansiation -- and it's a topic I will write about the perils of later.