Events and Delegates - Part I

by agrace 1. September 2007 09:46

This is part one of a series of posts on events and delegates, a powerful means of implementing loosely-coupled designs. This part will focus on delegates. You can read part two here.


As a developer, I think it took me longer than necessary to get my head around the code details of the event/delegate paradigm. In retrospect, I believe this was mainly due to my lack of understanding of the delegate type, which connects everything together.

Another problem I encountered was a lack of consistency of language and definitions used by the authors of books and articles on events and delegates. More on this later.

Publishers + Subscribers = Observer Pattern


There is no need to have a PhD in anonymous methods, function pointers, multicast versus single cast delegates and the like, in order to get started with events. What you do need is a basic understanding of the central piece of the jigsaw: the delegate. Next, you need to get an overview of the Publish-Subscribe model. Finally, you need to open up your code editor and create a basic event sample for yourself.


Generally, delegates (or callbacks) are typesafe pointers to methods, similar to function pointers in C++. We can use delegates to specify callbacks and also to register handlers for GUI events like button clicks. Unlike function pointers, which can only contain the address of a static method, a delegate can refer to instance methods in classes - this is what makes them tremendously useful. A delegate is like an interface: the difference is that the delegate declares a single static or reference method, whereas the interface can declare several methods. Whenever we want classes to communicate with less coupling than with an interface, we should use a delegate. In other words, delegates are not only for use with events!

If we need to specify an action or method in advance and we don't know which method, or even object, that will perform this action, we should use a delegate. For example, we can connect a button to a delegate and at runtime we can resolve that delegate to a particular method to be run.


A delegate is a special type in .NET whose main role in life is to hold a reference to a method. Delegates are defined with a signature, much like methods, and can only hold a reference to a method which matches this signature. We declare a delegate by using the "delegate" keyword and specifying the signature of the method to which it holds a reference. The following is a declaration of a delegate that can reference a method that takes two parameters and does not return a value:

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


The delegate is a TYPE; think of the entire statement above as a type. A method matching this signature would look like this:

public void Button_Clicked(object sender, EventArgs e);


In the following example, the delegate called SampleDelegate can invoke any method that is passed a string parameter and returns an int:

delegate int SampleDelegate(sting str);


We can now initialize a new delegate, like so...

SampleDelegate del = new SampleDelegate(DoSomething);


 ... and can call the delegate as follows:




A final point regarding terminology. When we talk about classes, we use two separate terms: class and object. With delegates, there is only a single term. An instance of a delegate class is also known as a delegate. So, we need to pay attention to context here. I will come back to the issue of terminology in the next post which will focus on events.

kick it on

Tags: ,


CSS Background Property Syntax

by agrace 19. August 2007 06:18

One of the trickier forms of CSS syntax is that of background properties, especially when using the shorthand form. This post will focus on the background-image property. When used correctly, the background-image property will enable you to create visually superior websites. Many of today's top Web 2.0 sites use this property, often combined with a repeating gradient image that blends into a background color.

First, an overview of the complete set of background properties and some brief descriptions:

Property Description
background Shorthand to set all background properties
background-attachment Sets background image as fixed or scrolled
background-color Sets background color of element
background-image Sets an image as the background
background-position Sets starting position of background image
background-repeat Sets how background image is repeated

For a more detailed breakdown, please see the W3Schools website.

The background properties can be brought together into a single line of shorthand CSS. We do not need to specify all the property values; we can use any one or more of them as follows:

Values [background-attachment] || [background-color] || [background-image] || [background-position] || [background-repeat]

If you have two values for the background-position property, they must appear together. And if we use length or percentage values, they must appear as horizontal first and vertical second. As long as you have at least one value present, you can omit all the rest. Other than that, there isn't any restriction on the order or particular properties to be included. If you omit any property values, then their default values are applied automatically. So, the following two declarations render the same output:

body { background: white url(test.gif); }
body { background: white url(test.gif) top left repeat scroll; }

The page you are looking at had its left navigation and main content area colors set by using a single 780 X 5 pixel, vertically-repeating image. The following CSS was employed:

background: url(img/main.gif) repeat-y;

This shorthand syntax is faster to type and easier to use than the full version. Using background images is an incredibly powerful way to take control of the overall look of your website.



I've often jokingly thought to myself that if I was ever pulled over by a member of the Californian constabulary using a speed detection radar gun, that I would demand to see the source code in court. I'm neither a lawyer nor a physicist, but my intuition tells me that machines used for measuring anything need to be calibrated correctly and frequently. In addition, they are driven by software. Hypothetically speaking, since I would never break the speed limit, just because a machine tells someone I'm speeding, that doesn't make it so. Software never makes mistakes, right?

On a similar note, the Minnesota Supreme Court recently ruled that the makers of the Intoxilyzer 5000EN Breathalyzer turn over the source code by August 17 to defense attorneys for use in a DUI case. Since this is not likely to happen, the guy will most likely walk free. Interestingly, it seems that the Intoxilyzer is based on the old Z-80 microprocessor from 1976. The software that runs the breathalyzer is 24K worth of sophistication. This would be funny if it wasn't so serious. Peek me, poke me, but don't send me to prison on the word of an antique games chip as an expert witness.

The gap between technology and some form of sensible, enforceable legislation continues to widen. And it's not just speed guns and breathalyzers. Recently, a spate of traffic light cameras have appeared in my local twin-city area. Some say that they solved local budget woes overnight with the almost $400 fine for busting a light. If you go before the court, they present nice shiny B+W pictures of your face and your license plate. "Yes, that's me and that's my car. But where's the picture of the traffic light your honor? It was as green as the fields of Ireland when I drove though it..."

Speaking of tickets, we have the speed monitored here by aircraft. If you end up in court as the result of a radio call from the pilot to the police officer, make sure the pilot is present in court along with the police officer when you cross-examine the witnesses ;-)