Archive for October, 2006

Close the windows, please!

We went on a safari yesterday, in Safari Park Beekse Bergen in the Netherlands. The kids loved it, and I must admit it is quite impressive to drive your car through the park with nothing but a thin window between you and the lions. They don’t look too hungry, but you never know!

It’s not as if the lions are the only big animals you can watch from just two meters away. Rhinoceros, elephants, zebras, and all sorts of deer are all quite impressive when you get so close to them. Not to mention the giraffes, when they start running towards you!

Definitely a family day out I can recommend!

Advertisements

Free e-book on Threading in C#

Even if you think you know all there is to know about Threading in C#, this free e-book is worth a read. And you can download it as a pdf too!

Properties with property changed event

I often coach or teach .NET developers, and I’m often surprised how some folks write the most complex programs and discuss amazing architectures, but can’t get the basics right. So I’m planning to write a series of posts on .NET basics. I’ll use C# as a language, but most topics will be equally applicable to Managed C++ or Visual Basic.NET.

In this first post, I want to talk about simple properties with a changed event, as you will often find them on classes used in Windows Forms data binding scenarios. Take as an example a “Name” property of type string. We’ll use a backing field called “name”. In VB you can’t rely on casing to differentiate between the field and the property, so you’d probably call the field “nameValue” or something. The getter will simply return the field, but the setter needs to raise the event in addition to setting the field.

According to .NET standards, the event will be of type EventHandler and be called NameChanged. Any other type or name, and Winforms data binding will not work.

Many people write something along the lines of

private string name;

public string Name
{
    get { return name; }
    set    
    {        
        name = value;
        if (NameChanged != null)
        {
            NameChanged(this, e);
        }
    }
}

public event EventHandler NameChanged;

But that has approach has two problems associated with it. The first one is the easiest to understand: the NameChanged event will be raised, even if the Name didn’t really change. Let’s say the value of Name is null and I write

Name = null;

That will raise the event, even though nothing changed. That could result in wasted processing or worse. In the case where two such properties are bound to each other via their events, any assignment to either of them would cause an infinite recursion and a stack overflow. So you need to test if the value really changed before raising the NameChanged event.

The second problem has to do with inheritance. If your class might be used as a base class for derived classes, you need to give those derived classes an easy and efficient mechanism to react to a property change. Raising an event and then subscribing to that event yourself doesn’t count as efficient. So what we do instead is create a protected virtual method that raises the event. This allows derived classes to override the method to be notified of property changes. Simple, clean and efficient. According to .NET standards, we’ll call the method OnNameChanged. Event raising methods like this one have a single parameter of type EventArgs (or, in the general case, a class derived from EventArgs). That yields the following implementation:

private string name;

public string Name
{
    get { return name; }
    set
    {
        if (value != name)
        {
            name = value;
            OnNameChanged(EventArgs.Empty);
        }
    }
}

public event EventHandler NameChanged;

protected virtual void OnNameChanged(EventArgs e)
{
    if (NameChanged != null)
    {
        NameChanged(this, e);
    }
}

You can of course extend this basic pattern. For example you could make the property virtual as well, although that would slow it down considerably. Anyway, the pattern as above is quite a bit of typing as it is, and will cover most cases.

In part 2 of this series, where we talk about an alternative approach: using the INotifyPropertyChanged interface.

Hello world!

In AustriaSome people keep on asking me why I don’t blog. It seems it’s just something one should do in the twenty-first century. Then again, I often enjoy reading other people’s blogs, so maybe I should indeed return the favor. I looked around a bit for a site to host it, and I found WordPress.com. It looks good (technically speaking, I’ll work on the graphics…), and it seems to have the features I want (including the must have RSS feed).

So now I have to deal with the white sheet of paper, and fill it. I guess I’ll be sharing experiences from my boring hobbies and fun work with you. Expect technical stuff, mostly on .NET. Geeky stuff maybe. But you might also get to see some of the pictures I shoot. I might even be funny from time to time. Well, I’ll leave that up to you to decide.

Talk to you soon.