C#

Enumeration (Enum) Gotcha

Adam Calderon — Tue, 08 Aug 2006 22:59:00 GMT

Enumerations can make your code much easier to read but there is one thing you should watch out for when using them. Before I get into what to watch out for let me define what an enumeration is. An enum type is a distinct value type with a set of named constants. An enum type that does not explicitly declare an underlying type has a type of int. So this means that by default an enum can have a range of values (constants) equivalent to an int. The set of values that an enum type can take on is not limited by the enum members. In fact any value of the underlying type of an enum can be cast to the enum type and is a distinct valid value of that enum type. These last statements are the basis for a Gotcha you need to watch out for when using enumerations.

The fact that an enum can be any valid type of the underlying type allows things like this to happen.

// Variable is created and assigned a value of ProductType.Commercial
ProductType productType = ProductType.Commercial;

// Variable is assigned a new value that is out of range
productType = (ProductType)100;

You need to keep this in mind when creating methods and properties that accept enumerations. Sure most of us use Visual Studio to create our applications and most of us would use the enum type instead of doing something odd like above but the fact you can do it can lead to some interesting results in your application. Here is an example of a method that doesn’t check for valid values.

        /// <summary>
        /// This method accepts a ProductType enum as a parameter and throws an exception if the
        /// value is out of range.
        /// </summary>
        /// <param name="type">A valid ProductType enumeration</param>
        static void AcceptProductType(ProductType type)
        {
            // The switch will not blow up if the value is not in range
            switch (type)
            {
                case ProductType.HouseHold:
                    Console.WriteLine("AcceptProductType Message: This is an enum with a value of " + type.ToString());
                    break;
                case ProductType.Commercial:
                    Console.WriteLine("AcceptProductType Message: This is an enum with a value of " + type.ToString());
                    break;
            }
        }

As you can see without checking the parameter this switch statement would never do anything if an invalid value was passed in. This could be resolved by using a default statement in the switch and throwing an exception but that could get messy if the method only worked with a few values of the enum. A better approach would be to check the parameter and throw an exception right at the top of the method like the following method.

        /// <summary>
        /// This method accepts a ProductType enumeration and validates that the parameter is
        /// of type ProductType
        /// </summary>
        /// <param name="type">A valid ProductType enumeration</param>
        static void AcceptProductTypeRevised(ProductType type)
        {
            // Check the parameter to see if the value is correct
            if (Enum.IsDefined(typeof(ProductType), type) == false)
            {
                throw new ArgumentOutOfRangeException("This value is not in the range for the enum type ProductType");
            }

            // Do some work
            AcceptProductType(type);
        }

This approach identifies the issue right away and never lets the method execute if the parameter is incorrect. This type of defensive programming can save a lot of time when it comes to testing your code. I have included a sample console application that demonstrates this.

EnumSample.zip (16 KB)

Slides and Code from the C# New Features Presentation at the .NET Developers User Group last Tuesday

Adam Calderon — Mon, 07 Aug 2006 11:22:00 GMT

Here are the slides and sample code from the presentation on C# I did at the .NET Developers Users Group last Tuesday.

Advanced Introduction to C#.ppt

CSharpIntroDemo.zip

Debugger Attributes

Adam Calderon — Thu, 03 Aug 2006 16:54:00 GMT

When debugging applications sometimes it’s really nice to be able to tweak things a little. Say you are stepping through segments of your code time and time again and you are tired of stepping into the property getters of your class as you pass a property as a parameter into a method. Or how about when you are using the new debugger visualizers and would love to see some highlights of your custom class without having to click the + sign. In the System.Diagnostic namespace are a few real handy attributes that can make your life easier when debugging.

First is the DebuggerStepThrough Attribute which stops the debugger from stepping into a class, constructor or method (to name a few). If you decorate your property getter when you F11 into a property you will no longer step into your getter code. Below is an example of applying this attribute.

     public string Address
        {
            //this attribute stops you from going into the address getter
            [DebuggerStepThrough()]
            get { return address; }
            set { address = value; }
        }

    /// <summary>
    /// This class uses the DebuggerStepThrough attribute to stop the debugger
    /// from entering any of the properties getters or setters.
    /// </summary>
    [DebuggerStepThrough()]
    class Customer2
    {
         ...code goes here
    }

Next is the DebuggerDisplay Attribute (which is new to .NET 2.0) and is used to display information to the debugger visualizer. The constructor of this attribute accepts a string which is displayed in the value column for instances of the type in either the locals window or the visualizer. The string can contain braces ({ and }) and the text within a pair of braces is evaluated as the name of a field, property, or method. Below is an example of applying this attribute.

     /// <summary>
    /// This class uses the DebuggerDisplay attribute to show highlights of information
    /// stored in the class. This information is displayed in the debugger visualizers
    /// and in the locals window.
    /// </summary>
    [DebuggerDisplay("FirstName={firstName},LastName={lastName}")]
    class Customer3
    {
        #region Members
        private string firstName;
        private string lastName;
        private string phone;
        private string address;

#endregion

        #region Properties
        public string Address
        {
            get { return address; }
            set { address = value; }
        }

        public string Phone
        {
            get { return phone; }
            set { phone = value; }
        }

        public string LastName
        {
            get { return lastName; }
            set { lastName = value; }
        }

        public string FirstName
        {
            get { return firstName; }
            set { firstName = value; }
        }

#endregion
}
}

In the editor the attribute changes the default behavior of the visualizer (see below)

and in the locals window the attribute changes the value entry (see below).

Finally there is one more attribute that can come in handy when you are using third-party code. The DebuggerNonUserCode Attribute is used to both hide the values from the debugger (similar to the DebuggerHidden Attribute) and stop the debugger from stepping into the code (similar to DebuggerStepThrough Attribute). This attribute can be applied a class, constructor, method or property.

Here is a sample project that you can use to see how these attributes work.

DebugAttributesDemo.zip

Code Camp Content

Adam Calderon — Mon, 23 Jan 2006 06:23:00 GMT

For those of you at my C# session the sample console application contains all of the Generics, Iterator and Property Accessor code. I recommend going through the code and changing things around to get a better feel for how the technology works. The WinForms application I showed with the Anonymous methods is also included.

Introduction to C# Slides and Demo Code

For those of you in my WinForms session I have included the sample code for everything we talked about. The object based application we went over in detail is the OrderEntryDemo application. This application is a great one to add more and more functionality to. One of the attendees was asking about editing a collection of data in a grid. Connecting the Order class to a grid, since it’s based on BindingList would be an excellent project to take on.

Introduction to Winforms Slides and Demo Code

BindingList a new way to bind lists

Adam Calderon — Mon, 16 Jan 2006 19:10:00 GMT

In .NET 1.1 binding to a list required a lot of work. First you had to inherit from Collection base and implement all of the Collection interfaces so that the caller could add and remove and move through your collection in a type safe way. Then you had to implement IBindingList which afforded your list the ability to keep up to data as a user edited your collection when bound to a grid. When all of this was said and done you had quite a bit of work to do.

public class CustomersList : CollectionBase, IBindingList
{
// all of the implementation went here

}

Now in .NET 2.0 this work has been dramatically reduced. A new class BindingList has been added that inherits from Collection and implements IBindingList, IList, ICollection, IEnumerable, ICancelAddNew, IRaiseItemChangedEvents. By having all of this wrapped up for you creating a list of cutomers you can bind to is a simple as:

BindingList customerCollection = new BindingList();

This statement performs what one took many many lines of code. The customerCollection variable can now be bound to a grid and work with in row editing and all of the new features of the DataGridVeiw. Now there are still a few things left to do. First you have to add data to the collection (of course) but one other thing is to have the Customer class implement INotifiyPropertyChanged and IEditableObject. The IEditableObject is the same as before but the INotifyPropertyChanged interface implements a pattern that was originally accomplished by adding a XXXPropertyChanged event for each property in your class. The code below demonstrates the changes. As you can see removing the need for the many XXXPropertyChanged events saves a lot of coding.

public class Customer : IEditableObject, INotifyPropertyChanged
    {
        private bool editMode = false;

        private int number;
        private int _number;

        public int Number
        {
            get { return number; }
            set { number = value; OnPropertyChanged("Number"); }
        }

private string name;
private string _name;

        public string Name
        {
            get { return name; }
            set { name = value; OnPropertyChanged("Name"); }
        }

private string street;
private string _street;

        public string Street
        {
            get { return street; }
            set { street = value; OnPropertyChanged("Street"); }
        }

private string city;
private string _city;

        public string City
        {
            get { return city; }
            set { city = value; OnPropertyChanged("Street"); }
        }

private string state;
private string _state;

        public string State
        {
            get { return state; }
            set { state = value; OnPropertyChanged("State"); }
        }

        public Customer() { }

        public Customer(int number, string name, string street, string city, string state)
        {
            this.number = number;
            this._number = number;
            this.name = name;
            this._name = name;
            this.street = street;
            this._street = street;
            this.city = city;
            this._city = city;
            this.state = state;
            this._state = state;
        }

#region IEditableObject Members

        public void BeginEdit()
        {
            if (!editMode)
            {
                _number = number;
                _name = name;
                _street = street;
                _city = city;
                _state = state;
            }

editMode = true;
}

        public void CancelEdit()
        {
            if (editMode)
            {
                number = _number;
                name = _name;
                street = _street;
                city = _city;
                state = _state;
            }
            editMode = false;
        }

        public void EndEdit()
        {
            editMode = false;
        }

#endregion

#region INotifyPropertyChanged Members

public event PropertyChangedEventHandler PropertyChanged;

        private void OnPropertyChanged(string propertyName)
        {
            if (PropertyChanged != null)
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }

#endregion
}

Anonymous Methods

Adam Calderon — Sat, 28 May 2005 20:27:00 GMT

I was recently doing some research into Anonymous Methods and began to realize how much coding they could save me in some situations. I have always wished for a shortcut to creating code that responds to events. It has always been a pain to create a method with the (object sender, EventArgs e) signature only to have that method call into something else. Now with Anonymous Methods I don’t have to do that.

So what are Anonymous methods? They are fragments of code that are used with delegates and are written in-line where you would normally reference a method name. The sample below illustrates how this works and compares the old way to the new way.

//old way

addButton.Click += new EventHandler(AddClick);

//new way

addButton.Click += delegate { MessageBox.Show(“Button was clicked”) };

All that you have to do is have the delegate keyword and insert your code between the { } and away you go. There are of course some restrictions on what you can do. The sample below gives you a good idea what you can and can’t do. The form has two buttons normalButton which illustrates your normal event handler and anonymousButton which illustrates an anonymous method.

namespace Anon_Methos_Events

{

public partial class Form1 : Form

{

public Form1()

{

InitializeComponent();

//standard and would normally be done by VS inside the form1.Designer.cs code

this.normalButton.Click += new System.EventHandler(this.btnNormal_Click);

//(1) This version works due to implicit conversions

this.anonymousButton.Click += delegate

{

MessageBox.Show("This was done inline with anonymous methods using no parameters and no () after the delegate keyword");

};

//(2) This version is the same as (1) except calls a method

this.anonymousButton.Click += delegate

{

TestAnonymous.MakeSomethingHappen();

};

//(3) This version works because this parameter signature matches

this.anonymousButton.Click += delegate(object sender, EventArgs e){

MessageBox.Show("This was done inline with anonymous methods using parameters");

};

//(4) This won't work because the empty () indicates that there are no parameters which is incorrect

//this.btnAnonymous.Click += delegate()

//{

// MessageBox.Show("This was done inline with anonymous methods using no parameters and no () after the delegate keyword");

//};

}

private void btnNormal_Click(object sender, EventArgs e)

{

MessageBox.Show("This is a normal event delegate");

}

public static class TestAnonymous

{

public static void MakeSomethingHappen()

{

MessageBox.Show("Something happened");

}

What is going on with (1) and (2) is that an implicit conversion is occurring from the anonymous method to the EventHandler delegate type (the type of the anonymousButtons event). This implicit conversion is possible because the parameter list and return type of the delegate type are compatible with the anonymous method. In (3) the parameter list for the delegate matches what is expected. In (4) by putting the () at the end the implicit conversion can’t happen and therefore the code will not work. For a complete reference for Anonymous Methods visit the Beta2 SDK online at http://msdn2.microsoft.com/library/0yw3tz5k(en-us,vs.80).aspx