'Adventures in .NET' Blog RSS Feed

My BLOG has moved

spickersgill — Sat, 25 Jul 2009 10:28:34 -0800

I've moved my BLOG to blogger. Please renew any stored links to this new address (http://dotnetadventurer.blogspot.com)

Debugging Client Side JavaScript using Firebug's Console

spickersgill — Wed, 15 Jul 2009 07:37:28 -0800

Firefox is among the most useful of tools to web developers. Not only for viewing web pages you create on an alternative web browser, but also due to the plethora of add-ons available for it. Foremost among these add-ons is Firebug, a feature that presents a GUI for drilling through any web page and viewing the CSS, HTML and Script.

[includeimage:1]

Firebug in use...

How to get Firebug

Get Firebug by following these simple steps;

1) In Firefox's menu go to Tools -> Add-ons

2) In the Add-ons dialog click "Get Add-ons" on the toolbar

3) Type "firebug" into the search box

4) Expand Firebug in the results list and click the "Add to Firefox..." button.

NOTE: If Firebug isn't listed when the results appear click on the "See all results" link at the bottom of the results list. This will take you to the full results listing where you will be able to add the add-on to Firefox.

Using Firebug

Once Firebug has been installed and Firefox has been restarted you'll notice the Firebug icon has appeared in the bottom right icon tray of Firefox. Click this icon to open Firebug. Click the "Inspect" button and move your mouse around the web page you're currently viewing. You'll notice that a blue rectangle appears to represent each HTML element, such as div, span, table etc in the underlying HTML. Click to display the details of the underlying HTML within the Firebug UI.

The Console

This is a really useful aspect of Firebug that provides an output for you to write to in your client script, and can be used extensively for debugging your client script.

You will need to enable the console for sites you wish to use it on:

[includeimage:2]

Once you've done this, Firebug will expose an object in Firefox simply called "console", which you will then be able to call in your script. You can read the Console documentation at http://getfirebug.com/console.html Pay special attention to the String Substitution Patterns which allow you to output different data types, most notably objects, to the console.

A brief code example should help to explain:

<script language="javascript" type="text/javascript">
	
        function debug(obj) {
            if (console)
                console.log("%o", obj);
        }

</script>

This function allows your JavaScript code to write an object to the console. The "%o" substitution pattern means that Firebug will interpret the passed parameter as an object, and will represent it in the console as a browsable tree, much the same way that the local window does in Visual Studio.

[includeimage:3]

Apart from the above there are many other useful methods available on the console object, described in the API documentation (http://getfirebug.com/console.html) that will make your JavaScript debugging much, much easier.

The Script Debugger

The Script debugger also needs to be enabled on a site by site basis. Once enabled the underlying HTML will be displayed in the Script window. As you scroll through the source you will notice that any embedded script appears with green line numbers. You can click any green line numbers to place a stop in the code, again very much the way you may be used to in IDE's such as Visual Studio.

[includeimage:4]

Aspects of Polymorphism in .NET Part 4 - Interfaces

spickersgill — Wed, 08 Jul 2009 06:30:46 -0800

Part Four: Interfaces

If you've read parts 1-3 of this blog you'll be aware that we've used the real world objects, cars, to draw a parallel with, and explain, classes, inheritance and abstraction. I hope that, by this stage, you are beginning to undertand and recognise the advantages that come from properly object orienting your code. Flexibility for future development is a key aspect of proper OO design.
Although the code examples in this BLOG have been written in C#, one of the .NET languages, the principles apply to all Object Oriented languages.

So, we now come to Interfaces. What role do they have in object oriented programming?

Contracts

I have often read that Interfaces can be likened to contracts. The thinking behind this analogy is that a class implementing an interface MUST implement ALL of the methods and properties declared by the interface, much the way that an employee MUST carry out all of the responsibilities contained in his contract of employment if he wants to keep his job. However, I don't really find this analogy to be particularly helpful as it doesn't really explain why you'd bother to create or implement an interface in the first place. So, I'm going to explain the use of interfaces by extending our hypothetical car model already used throughout this BLOG. I sincerely hope that this will clarify the use of interfaces for any of you who are a little confused about them.

Recap

At the end of part three you should have started to see that by abstracting a "Car" class and implementing that abstract class in our "Focus" class we could then build other classes that made use of Cars (generic and flexible) rather than specific models such as Focus (narrow and restrictive). An abstract class was ideal for the "Car" because it allowed us to implement logic that was common to all cars within the abstract class, and declare abstract methods for logic that would have to be implemented by sub classes.

Manual or Automatic?

In the UK (where I'm from) 90% of the cars on the road are manual transmission with the vast minority being automatic. Drivers who take their driving test in an automatic car are restricted to only being able to drive automatic cars. On the other hand, those who pass their test in a manual car can drive either manual or automatic. Modelling this behaviour in our example case is an ideal environment for interfaces.

Although it's not compulsory, it is common practice to precede the name an interfaces with a capital "I". So, let's create interfaces that define manual and automatic cars.

    public interface IManual
    {
        bool ClutchDepressed
        {
            get;
            set;
        }

        void ShiftUp(int gearFrom, int gearTo);

        void ShiftDown(int gearFrom, int gearTo);
    }

    public interface IAutomatic
    {
        void ShiftDrive();

        void ShiftReverse();

        void ShiftPark();
    }

You will notice that our interfaces contain no implementation (i.e. logic that says how to do any of the things declared), they simply declare methods and properties that any implementing classes MUST provide logic for.

So, when the hypothetical engineers at Ford build different models of the Focus, they will implement one of these interfaces depending on the kind of transmission they will be using. Let's go back and update our code in order to implement one of these interfaces.

    public class FocusAuto : Focus, IAutomatic
    {
        public FocusAuto(Guid keyCode)
            : base(keyCode) { }

        public FocusAuto(Guid keyCode, int numDoors) : base(keyCode, numDoors) { }


        public void ShiftDrive()
        {
            //... Logic to change the gear into Drive and 
            // then automatically through the gears as the car moves ...
        }

        public void ShiftReverse()
        {
            //... Logic to change the gear into Reverse ...
        }

        public void ShiftPark()
        {
            //... Logic to change the gear into Park ...
        }

    }

You'll notice that I've created a new class, called FocusAuto. This means that we've managed to avoid changing our existing Focus class. Focus, still implements Car, so we still benefit from all of the logic contained in Focus and Car. However, as highlighted in blue, the new FocusAuto class implements the IAutomatic interface. As a result it MUST implement the three methods declared by the interface.

The Benefits

Why put this definition in an interface? After all, the FocusAuto class could easily have contained the logic without implementing the IAutomatic interface. Simply remove the , IAutomatic from the class definition and the code will still compile...

The reason is simple and yet very powerful - and remarkably similar to the benefits we derived from abstracting logic into a Car class...

Earlier I mentioned that interfaces are often likened to contracts. Think about what contracts do... For example, your employment contract defines what is expected of you as an employee. However, it also serves as a marker or identifier for YOU. If you have a contract that defines the role of a C# developer that is what you are.

Interfaces do the same for classes - they act as identifiers for what the class is, or does. So, we can now diffentiate drivers based on what they are allowed to drive. Let's create a new class to demonstrate this

    public class AutomaticDriver
    {
        private Car myCar;

        public IAutomatic MyCar
        {
            get
            {
                return (IAutomatic)myCar;
            }
            set
            {
                myCar = (Car)value;
            }
        }

        public void Init()
        {
            Guid _keyCode = new Guid();
            if (myCar != null)
            {
                myCar.Start(_keyCode);
                myCar.Accelerate(0, 50);
                myCar.Brake();
            }
        }        
    }

Because our AutomaticDriver class doesn't really care about who made the Automatic car it drives all it has to do is check that the car is an automatic. Therefore any car that implements the IAutomatic interface will be allowable.

            FocusAuto myAuto = new FocusAuto(new Guid());
            AutomaticDriver driver = new AutomaticDriver();
            driver.MyCar = myAuto;

Summary

Throughout this BLOG on polymorphism you have seen that there is much to be gained by OO design - designing at the interface level rather than the object level. In fact, this is the basic premise of Design Patterns (recommended for further reading).

I have used a real world parallel in order to convey these concepts because I often find it easier to understand new concepts by looking for every day instances around me. I hope you have found this series to be helpful and insightful.

Aspects of Polymorphism in .NET Part 3 - Abstract Classes

spickersgill — Thu, 25 Jun 2009 07:55:01 -0800

Part Three: Abstraction

All of us are aware of abstract concepts, although perhaps we aren't aware that we're aware. To explain... all of us know that there are things we can touch, possess, and things that we can't. For example, we all eat food, but we never actually have a food. Food is an abstract concept and we actually eat instances of food - apples, hamburgers, pizzas, carrots, etc.

Abstraction is at the top level of most things we're familiar with on a day to day basis. In our Ford Focus illustration we were dealing with a concrete instance of an abstract concept - vehicle. Although a person may be said to own a vehicle, it's meaningless without specifying the type of vehicle he or she possesses. For most of us this is a car, but for some it might be a plane, a boat, a bike, a helicopter etc. We then further solidify things by becoming more and more specific about things - what make, model, variation of car we have, for example.

In programming terms abstraction allows us to define a very loose model for something without specifying exactly how the implementation will be handled. Abstraction comes in varying degrees in the programming world. There are Interfaces, which are completely abstract (contain absolutlely no implementation code), and abstract classes, which can contain a mixture of abstract methods and implementation code. This will all be explained before long, so don't worry if you don't understand these terms just yet.

We'll start by moving one step up the vehicle abstraction hierarchy from our Focus, to the Car to explain abstract classes. Cars come in all different shapes and sizes, but all working cars share certain characteristics, no matter how new, old, cheap or expensive they are. They all start, stop, move, turn etc. How these characteristics are accomplished though, can be different from one car to the next. For example, one manufacturer may start the car by a simple key turn, another by a push button, yet another by fingerprint recognition. On the other hand, though, some things are common between all cars - they are all driven by an engine, stopped by brakes etc. These rules apply for cars, but not for other types of vehice - sailing boats, for example, are driven by the wind and stopped (if in a hurry) by an anchor.

So, if we were to extend our model code for the Focus we would have to say that our Focus is a concrete implementation of a Car (abstract class). Of course, because we're building our code in the order in which wer're covering the topics in this blog, we'll next be building our abstract "Car" class. In pratice, we would design our classes using a modelling tool such as UML, designing interfaces and abstractions up front - the inverse to the way wer'e doing things in this blog - and code concrete classes on the basis of our abstractions. For further reading on the matter Google "Design Patterns" or "Gang of Four".

There is a lot to be said for abstracting functionailty, but I strongly believe that you need understand the bigger picture first.

Let's have a look at how we code an abstract class in C#:

namespace Ford
{
    public abstract class Car
    {
        public abstract void Start(Guid keyCode);
    }
}

This is a very basic start, but it demonstrates all that we need to show for now... First of all notice the use of the keyword abstract. This marks the class as being abstract, so instances of this class cannot be created. So,

Car c = new Car();

will result in a compilation error:

Cannot create an instance of the abstract class or interface 'Ford.Car'

Next we have an abstract method:

public abstract void Start(Guid keyCode);

Notice that this method doesn't have a body (i.e. no curly braces). That's because the method is abstract - its implementation, or how it will start, must be coded in a class that implements this abstract class. We'll soon see how this affects the Focus class, which we'll alter to implement the Car class.

However, abstract classes can contain implementation logic too, which is then inherited by the classes that implement it. For example, since in our fairly basic example, we can safely assume that all cars will accelerate by engaging the engine and stop by engaging the brakes, we can promote this logic to the abstract class level. Then all cars will benefit from this standard logic.
Our modifies abstrat class now looks like this:

   public abstract class Car
    {
        protected Engine _engine = new Engine();
        private double _currentSpeed;
        private Brake[] _brakes = new Brake[4] { new Brake(), new Brake(), new Brake(), new Brake() };

        public abstract void Start(Guid keyCode);

        public void Accelerate(double initialSpeed, double endSpeed)
        {
            while (_currentSpeed < endSpeed)
            {
                _engine.Throttle();
            }
            _engine.Idle();
        }

        public void Brake()
        {
            _brakes[0].Apply();
            _brakes[1].Apply();
            _brakes[2].Apply();
            _brakes[3].Apply();
        }

    }

Now we'll look at the changes we need to make to our Focus class in order to implement the Car class.

As a reminder, let's look at the code as it was:

public class Focus{
    private Engine _engine = new Engine();
    private double _currentSpeed;
    private int _doorCount = 4;
    private Guid _keyCode;

    public Focus(Guid keyCode){
	//Default constructor
	_keyCode = keyCode;
    }

    public Focus(Guid keyCode, int numDoors) : this(keyCode)
    {
	_doorCount = numDoors;		
    }

    public void Start(Guid keyCode)
    {        
	if(keyCode == _keyCode)
            _engine.Start();
    }

    public void Accelerate(double initialSpeed, double endSpeed)
    {
	while(_currentSpeed < endSpeed){
	    _engine.Throttle();
            
	}
	_engine.Idle();
    }

    public int DoorCount{
	get{
	    return _doorCount;
	}
	set{
	    _doorCount = value;
	}
    }

    // ...
    // ...

}

In order to implement the new Car abstract class the following changes need to be made:

    public class Focus : Car
    {
        private int _doorCount = 4;
        private Guid _keyCode;

        public Focus(Guid keyCode)
        {
            //Default constructor
            _keyCode = keyCode;
        }

        public Focus(Guid keyCode, int numDoors)
            : this(keyCode)
        {
            _doorCount = numDoors;
        }

        public override void Start(Guid keyCode)
        {
            if (keyCode == _keyCode)
                _engine.Start();
        }

        public int DoorCount
        {
            get
            {
                return _doorCount;
            }
            set
            {
                _doorCount = value;
            }
        }

        // ...
        // ...

    }

Notice the changes to the class:
1) We've added : Car to the class declaration. Just as with the extension of Focus into FocusLE, this notifies the compiler that we are going to be implementing the Car abstract class.
2) The Accelerate method has been removed since this logic is now contained in the abstract class.
3) We still have the Start method, although we've had to add the override keyword to the method statement.

Why do we get rid of Accelerate, but keep Start? Because Start is declared as an abstract method in the Car class. In other words it must be implemented in a child class, such as "Focus". On the other hand, Accelerate contains implementation logic within the abstract "Car" class and therefore doesn't need to be overriden in the "Focus" class - although it could be if needed.

Now, when we create an instance of Focus we get access to the Accelerate and Brake methods. Let's create a new class, called "Driver" and demonstrate this inheritance:

    public class Driver
    {
        public void Init()
        {
            Guid _keyCode = new Guid();
            Focus myFocus = new Focus(_keyCode);
            myFocus.Start(_keyCode);
            myFocus.Accelerate(0, 50);
            myFocus.Brake();
        }        
    }

The code highlighted blue demonstrates the fact that the "myFocus" object (i.e. the instance of the "Focus" class) can Accelerate and Brake even though "Focus" doesn't define these methods.

Why?

You may be wondering - "why is any of this useful?" Well, now that we've abstracted things out to the level of "Car" we can deal at that abstract level. Say for example, we were creating a class called "Garage". We can now easily build that "Garage" class around Cars rather than Focuses.

    public class Garage
    {
        public void Service(Car aCar)
        {
            //...
            //Code to Service the care
            //...
        }
    }

Because every "Focus" is also a "Car" (by virtue of the fact that it has implemented the "Car" abstract class) this, and any other class that implements the "Car" abstract class can now be serviced at the "Garage".

Once you understand the principles of abstraction it doesn't take long to realise the massive potential for it to make your code more flexible and extensible.

Summary

This tutorial has demonstrated what abstract classes are, and by the time you've finished reading this series of blogs on polymorphism I hope you will feel sufficiently equipped to go on to further reading, such as books on Design Patterns. These books will help you to get a stronger grasp on the far reaching benefits of abstraction.

The next and final part of this blog series will deal with interfaces.

Aspects of Polymorphism in .NET Parts 1 & 2 - Inheritance

spickersgill — Tue, 09 Jun 2009 09:21:12 -0800

An Introduction to Interfaces, Abstract classes and Inheritance

Introduction

.NET Developers come in various shapes and sizes, not only physically, but also in terms of their expertise and experience. The polymorphic nature of the .NET Framework now allows their code to benefit from similar diversity.
Sadly, though, it is entirely possible with .NET languages and tools, such as Visual Studio 2008, for developers to build programs and web sites without necessarily needing to know or understand the underlying complexity of what they are doing. I've come across so-called developers whose approach to solving problems has greatly improved their search engine skills as they scour the internet for code samples they can lift to fix the problem they're currently facing. Sadly, though, their attitude towards actually understanding and getting to grips with the problem domain is one of laziness.
For this reason developers can work commercially, producing viable code and making extensive use of the vast array of controls and tools at their disposal, yet not fully understand such basic lower level concepts as abstraction, inheritance and polymorphism. To be fair, though, this is quite understandable. After all, much of the documentation available on these topics is far from light reading, and tends to go to much greater depth than is necessary for the average beginner wanting to gain a basic understanding. This blog will therefore provide an easier access into these areas of object oriented (OO) programming techniques.

Part One: Object Orientation - What's all the Fuss?

I first came into .NET languages after years of developing solely in Visual Basic. Newer developers, who have only really got into the programming game since the inception of the .NET Frameworks will no doubt be a little confused by this statement. To explain... Visual Basic existed as a much more simple language prior to VB.NET. A VB developer was largely looked down upon by other members of the programming community (Java, Delphi, C++ etc) because Visual Basic was, rightly, viewed as an inferior language. Why? Because it masked a lot of complexity from the developers using it. Inheritance wasn't even an option.
During this period I started learning a little Java and had my first exposure to proper OO programming. At about the same time the first version of the .NET Framework was seeing the light of day, and my movement into C# from Java was therefore very organic.
So, what's all the fuss about? Well, Object Oriented programming allows a much more flexible and extensible approach to developing your code than you would otherwise have. Let's explain by means of a real world parallel, as I often find these to be the best aids.

If you drive, you no doubt, unless you're very wealthy (in which case, why are you reading this blog?), own a car built on a production line by one of the world's major car manufacturers. Your car started its life on a production line along with a load of other cars just like yours. Let's say, for example, that you drive a Ford Focus. Although your Focus is identical in shape and size to all other Focuses manufactured at the same time as yours, it isn't necessarily identical in all areas. Ford offers a diverse range of trim levels across the Focus range that affects such items as wheels, tyres, engine size, fuel type, leather or cloth seats etc.
However, although you may have requested a certain level of individuality for your car, Ford didn't have to send their designers back to the drawing board in order to build your car. They stuck with the basic design of the Focus and simply changed peripherals.
This is a real world instance of what Object Oriented programming techniques allow. A programmer can develop a class that does everything he or she wants it to. However, unless he seals the class, which prevents it from being extended (although Method Extensions in .NET Framework 3.5 can provide a workaround for developers wishing to extend sealed classes) another developer can extend or override aspects of the class so that it fits their own individual needs. This is called polymorphism (poly meaning "many" and "morph" meaning shape). When you stop to think about it you'll soon realise the potential benefits you can reap from this.

Part Two: Inheritance

If we were to draw a parallel to the above example in the programming world, engineers at Ford would have built what's called a base class and named it something like "Focus". This class would define and implement various properties and methods. For example:

public class Focus{
    private Engine _engine = new Engine();
    private double _currentSpeed;
    private int _doorCount = 4;
    private Guid _keyCode;

    public Focus(Guid keyCode){
	//Default constructor
	_keyCode = keyCode;
    }

    public Focus(Guid keyCode, int numDoors) : this(keyCode)
    {
	_doorCount = numDoors;		
    }

    public void Start(Guid keyCode)
    {        
	if(keyCode == _keyCode)
            _engine.Start();
    }

    public void Accelerate(double initialSpeed, double endSpeed)
    {
	while(_currentSpeed < endSpeed){
	    _engine.Throttle();
            
	}
	_engine.Idle();
    }

    public int DoorCount{
	get{
	    return _doorCount;
	}
	set{
	    _doorCount = value;
	}
    }

    // ...
    // ...

}

Now, let's say they decide to release a limited edition Focus that has a push button start, instead of a traditional key turn. One safety condition is that the clutch has to be depressed before the engine can be started. Several other novel features are added, but for the sake of simplicity this is the one we'll focus on (no pun intended).
Since the code for the base class is pretty much as it needs to be, the engineers can use inheritance to extend the existing functionality. They therefore create a new object called "FocusLE" (LE = Limited Edition).

public class FocusLE : Focus{
    
}

By using the ":" operator the compiler is told that this new class inherits from the "Focus" base class. The new class inherits all of base class' public and protected methods and properties. However, we now want to create a new Start() method that takes an additional parameter:

public class FocusLE : Focus{
    public void Start(Guid keyCode, bool clutchDepressed){
	if(clutchDepressed)
	    base.Start(keyCode);
    }
}

Because the new class inherits from the "Focus" base class the new Start() method can invoke the Start() method in the base class by use of the base keyword once it has done its check to make sure that the clutch is depressed. However, we don't want to leave the old Start() method publically exposed. So we have to do what's called hiding the base class' method.

public class FocusLE : Focus{
    public void Start(Guid keyCode, bool clutchDepressed){
	if(clutchDepressed)
	    base.Start(keyCode);
    }

    //override the StartMethod in the base class
    public new void Start(Guid keyCode){
	//Do nothing	
    }
}

Because the engineers who created the the base "Focus" class didn't anticipate a later revision with a different start mechanism they didn't declare the base class' Start() method using the virtual keyword. That's why we use the new keyword when declaring the hiding method. We could leave it out but the compiler would issue a warning. This hiding Start() method means that trying to start the new "FocusLE" without providing the second parameter will do nothing. If we hadn't hidden this method of the base class in our new class the old Start() method would still have been available and we would have had a potential safety risk.

Had the original engineers looked ahead and declared the original Start method with the virtual keyword we would have been able to override this in the "FocusLE" class.

public class FocusLE : Focus{
    public void Start(Guid keyCode, bool clutchDepressed){
	if(clutchDepressed)
	    base.Start(keyCode);
    }

    //override the StartMethod in the base class
    public override void Start(Guid keyCode){
	//Do nothing	
    }
}

Part Three: Abstraction

In part three of this blog I will expand our example to explain the idea of abstraction in object oriented programming. Part Four will look at Interfaces and what they're useful for.

Delegates Explained in Plain English

spickersgill — Fri, 05 Jun 2009 09:38:40 -0800

Delegates are fundamental to the .NET Framework (events and callbacks wouldn't work without them) and can be extremely powerful to the .NET Developer once they come to grasps with exactly what they are and how to use them. In this blog I will consider aspects of a real world situation in which delagates are useful, after which I will explain, in illustrative terms exactly what delegates are all about. You will see how delegates are an intrinsic part of the events structure in the .NET framework, but also why they are useful in their own right. First, though, we need to understand a little about the origins of delgates in the .NET framework.

The origins of delegates

Delegates in .NET languages such as C# and VB.NET are akin to function pointers in C++. I have found that simply being aware of this pseudonym it extremely helpful in understanding delegates. The term helps us to understand that delegates allow a developer to provide a pointer to a method/function/sub etc. But when would a developer find this to be useful?

Where delegates are needed

Let's say, for example, that you are developing a Windows Forms application and you want to open a new instance of a form. You want your new form to do some work and update its opener at some point down the line.

To expand, let's take a real world example. I developed a Windows Forms application in C# that was used for managing staff and contracts within a cleaning business. This was an MDI application and had toolbars on the MDI parent form with lists of staff and contracts so that the user could easily select a member of staff or a contract to work on. When the user selected a member of staff or contract a new form was opened. There was also, as you would expect, forms for creating new staff members and new contracts. These forms needed to update the main form whenever a new member of staff or a new contract was added to the system so that the main form could refresh its lists. In a basic application you might accomplish this by opening these forms modally directly from the main form and then updating the lists when the new staff form closes. Something along the lines of:

//... MainForm code ...
NewStaffForm _nuForm = new NewStaffForm();
_nuForm.ShowDialog();

//Assume that the user clicked the OK button on the
//NewStaffForm and added a new member of staff

RefreshStaffList();

However, this is extremely limiting. The ShowDialog() method for opening the NewStaffForm form holds execution of the subsequent code within the MainForm until the NewStaffForm has closed.

What if you want your application to be more flexible than that and keep your MainForm useable while the NewStaffForm is in use? What if you want your NewStaffForm to do more than just notify your MainForm that it's created a new user? Say, for example, you want it to pass information back to the MainForm? This is where delegates come in.

In particular, in this instance, an event would be useful; but as you will see, in .NET delegates are inseparable from events.

Revising our code to use delegates and events

No doubt you're very familiar with events and have made extensive use of events belonging to other objects. However, until you actually create your own events you probably don't really know or care what's going on. So, let's revise our code and explain what we're doing at each stage.

First, we want to declare an event handler in our code. It doesn't really matter where this event handler is declared so long as it has public scope so that it can be seen by other objects. A delegate can be declared outside of a class declaration, as it is essentially a type declaration, just as a class is.

public delegate void NewStaffCreatedHandler(StaffMember NewStaffMember)

Notice that this event handler is actually a delegate. Also, notice that it takes a parameter of type StaffMember. This is a custom type specific to this program. It's details are not relevant to this blog, so I'll go no further in describing it.

Next, we declare an event in our NewStaffForm.

public event NewStaffCreatedHandler NewStaffCreated;

Notice that the event has, as its type, the event handler we just declared.

Next, we write code to raise the event. This looks very much like a method call:

protected void CreateNewStaffMember()
{
    StaffMember _newStaffMember = new StaffMember();
    //... Code to create the new StaffMember...

    //Raise the event
    NewStaffCreated(_newStaffMember);
}

Where exactly is the code that runs when the event is raised? Remember what we said earlier about the origins of delegates lying in C++ function pointers. As I said, remembering this pseudonym helps to understand what delegates are all about.

When the event is raised we are actually calling the function(s) (or method(s)) that the delegate points to. How do we point the delegate to a method? Well, where events are concerned I'm willing to bet that it's something you already know how to do. We simply assign a method to the event be doing the following in our MainForm form.

//Create an instance of the NewStaffForm and assign a method to the NewStaffCreatedHandler
NewStaffForm _nuForm = new NewStaffForm();
_nuForm.NewStaffCreated += new NewStaffCreatedHandler(NewStaffForm_NewStaffCreated);
_nuForm.Show();

//This is the method that the delegate points to
void NewStaffForm_NewStaffCreated(StaffMember NewStaffMember)
{
    RefreshStaffList();

    NewStaffMember.AddedToList = true; //Do something with the StaffMember object that was passed with the delegate
}

Explaining what's happening in Plain English

Why are delegates called delegates?

In the real world a delegate is usually a person. What function do they serve? Well, imagine a large company wants to have a presence at a conference. The whole company can't relocate to the conference venue for its duration - that would be impractical. Rather, the company assigns a delegate (or delegates) to go and represent the company at the conference. The delegate might be given specific instructions about how he or she is to behave when there, which hotel they are to stay in, what their budget for food & drink is etc, but the delegate, being a human being, has relative freedom besides these constraints. When the delegate returns from the conference he or she may have to report back to the company about it.

In the .NET framework a delegate fulfils a similar purpose. Where one class may wants to be represented within another class it can use a delegate. This is a lot more efficient that passing itself to the other class in its entirety, and is a lot more flexible. The delegate has to conform to certain limitations, though, just as the real world delegate does.

When a delegate is declared it is declared much along the lines of a method/sub/function declaration. For example, in C#, a delegate declaration might look like:

public delegate void NewStaffCreatedHandler(StaffMember NewStaffMember)

It is given a scope public, a return type void (although it could equally be any other type), and specifies parameters. This constitutes the agreement as to how the implementation of the delegate (i.e. the method/sub/function it points to) must behave. In other words, any method/sub/function that this delegate points to must return a void and take a StaffMember object parameter.

The most common event handler delegate EventHandler, for example, has the following declaration:

public delegate void EventHandler(object sender, EventArgs e);

All events are of a delegate type. In other words, all events are declared with a specific delegate as their representative. For example, a delegate at a Microsoft conference could report back on an event that a delegate at an Sun conference couldn't (although they in turn could report back on an event that the Microsoft delegate couldn't), because they weren't in attendance at the same conference.

So, if you wanted to declare an event in your program that used the standard EventHandler delegate you would declare it as follows:

public event EventHandler MyEvent;

Delegates aren't restricted to events

Although we've used events as a springboard for our explanation of delegates, there's no reason to limit delegates to this useage. In the MDI application I mentioned above I didn't actually use events at all (although, as can be seen, I could easily have). I knew that I wanted my child forms to update my parent forms by means of a function call. This created the environment for the use of a delegate, but to save on the the extra declaration of an event in my child form I simply declared a constructor for my child forms that took my delegate as a parameter. For exeample:

public delegate void NewStaffCreatedDelegate(StaffMember 
NewStaffMember);

public class NewStaffForm : Form{
    public NewStaffForm (NewStaffCreatedDelegate callbackDelegate){
        //Constructor logic
    }
}

Then, when I wanted to callback to my parent form I simply invoked the delegate:

callbackDelegate(newStaffMember);

Passing a delegate to the constructor of the child form is very easy. Simply pass the name of the method that you want the delegate to point to. For example:

NewStaffForm myChildForm = new NewStaffForm(myCallBackMethod);

Don't forget, though, that the method being passed MUST agree to the rules set out for the delegate. So, it's signature must be the same as that of the delegate.

void myCallBackMethod(StaffMember newStaffMember){
   //Implementation logic
}

Summary

In essence, delegates allow one class to invoke code in another class, without necessarily needing to care where that code is, or even if it exists at all...

Let's go back to the conference scenario to explain. Microsoft may host a conference and send out invitations to many different partner companies. At the conference one of their lead developers may provide a sneak preview of a new product. Delegates in attendance may be given a beta copy to take back with them for trial. Microsoft doesn't care whether or not all of the companies they invited chose to send a delegate or not. Their conference won't halt just because one company declined to be represented.

Likewise, one class may expose a property, method parameter or event that allows another class to send a delegate to its code. The delegate (or more to the point the implementation of the delegate, the method/sub/function that the delegate points to) will have to conform to the delegate's signature. Most classes that send a delegate may choose to provide an implementation (i.e. logic for the method/sub/function) but some may not. The inviting class doesn't really care... it will still do what it does and make use of the delegate. For example, all TextBox control's expose a KeyPress event, but not every form that uses a TextBox control will choose to provide an implementation for the KeyPress handler. The TextBox control will still work, it's just that nothing will happen when a user presses a key within it - because no implementation of the delegate has been provided by the form.

In conclusion, as you will see from the above, once you understand what delegates are for, and what they enable, you will likely start to realise many different scenarios in which you can use them. I strongly believe that you can't really claim to be a .NET developer without understanding this fundamental part of the framework. If you've struggled to understand delegates in the past, or even if you've never really cared much about them before, I hope this blog will help to clarify matters and help you to become a better programmer.