Blogging on Demand #6

I saw this in my referral whatsit just this evening, in fact, so in the interests of rapid response, here's a little bit about...

"accessing protected methods" vb (via Google)

Any methods in your class can (and usually will) be given a level of access, normally one of four:

• Public
• Private
• Friend
• Protected

There are a couple more as well which are used quite a bit, Shared and Virtual. I won't be going into them right now, since the reasoning behind them is a little different to the other four.
The different levels of access denote which code can 'see' the method, and call it. Briefly, the levels of access look like this:

Public
Public methods (same with public variables) can be seen and called from any code that references it. If you add a reference to your project, and declare an instance of the class, you can call all the methods declared in that class as public.

Private
Private methods and variables are declared within your class and can only be callled from within that class. If you create an instance of your class that has private methods within it, you will ot be able to call those methods. I often use private methods for quick functions that are needed all over the place within that class. They can, in fact, cover a multitude of evils (just between you and me). You'll notice that when you're working in VS, intellisense doesn't list private methods either. It's clever like that. As far as the code calling your class goes, private methods may as well not exist. I think you get the point.

Friend
Methods and variables declared as friend can be called only by code from within its assembly. This is quite handy if you've got some code that's used extensively throughout your application, but has some secret logic in it (for instance). OK, there are ways and means of finding it, through ILDASM and stuff, but for normal developers doing normal things, it's pretty much invisible. It's also something to look out for if you're writing an app that has multiple assemblies. As far as I know, the scope of friend methods is only the individual assembly, rather than the whole application.

Protected
Finally. Protected methods. What this whole post was meant to be about. Protected methods really come into play when you're talking about inheritance. And why? Because protected methods can only be called directly by an inherited class.

Take, for example, the Windows Forms Control class. All Windows Forms controls have a protected sub called OnPaint. As the name suggests, it paints the control. You may want to, however, do some custom action while the control is painting. Because the OnPaint method is declared as protected, you can't call it from the surrounding code. It can only be called from within itself. So how can you do something whizzy and flash with your control's OnPaint method? Well, you can inherit from it.

Create yourself a new class, that inherits from Control, and within that class you can change the way your control is painted. I did this recently with a dial control I was working on. In my case, I used OnPaint to specify where the hand on my dial was going and to draw it in, by declaring this method:

Private Overrides Sub OnPaint(sender as object, e as PaintEventargs)
' Call the original base class' OnPaint, so you don't have to draw the whole thing from scratch
MyBase.OnPaint
'Do some drawing stuff here
End Sub

The important thing to note, however, is that the original MyBase.OnPaint method was available, because it was declared in the base class as Protected.

And that's how you access protected methods.