An often overlooked feature of C# (and OO programming in general) is the use of abstract classes to maximise code re-use. Put simply, if you have code in related classes that is the same but needs to call implementation specific methods, you can probably use an abstract class to consolidate this code. Lets dive right in with a simple example.

This is production code that has been stripped back to highlight the use of abstraction. In my scenario I had a number of user controls that had to implement the same functionality to each display three different views. The initialisation code ran through the same method calls in each control but the implementations of the called methods were different. Enter the abstract class …

public abstract class ControlBase 
{
    public int ViewMode { get; set; }
 
    protected abstract void SetSaveButtonEnabled();
    protected abstract void SetCollapsedView();
    protected abstract void SetSummaryView();
    protected abstract void SetExpandedView();
    protected abstract void HideAll();
 
    protected virtual void InitControl()
    {
        SetViewMode();
        SetSaveButtonEnabled();
    }
 
    protected virtual void SetViewMode()
    {
        HideAll();
        switch (ViewMode)
        {
            case 1:
                SetCollapsedView();
                break;
            case 2:
                SetSummaryView();
                break;
            case 3:
            case 4:
                SetExpandedView();
                break;
        }
    }
}

The InitView() and SetViewMode() methods are the same across all controls. Obviously the actual code to render the correct view is specific to the implementation of the control itself. So how does it work? Firstly, an abstract class can never be instantiated … it can only be inherited from. Any methods specific to the implementation are declared as abstract. In the abstract base class we know what the method signature should be but we can’t implement it at this level. Once the signature is provided and declared abstract we can call that method in the abstract class code as demonstrated in the SetViewMode() and InitControl() methods. At runtime this will result in the implementation of the method in the child class being called.

Our inherited class would look something like this …

 
public class Control1 : ControlBase
{
    protected override void SetSaveButtonEnabled()
    {
        //control specific code here 
    }
 
    protected override void SetCollapsedView()
    {
        //control specific code here 
    }
 
    protected override void SetSummaryView()
    {
        //control specific code here 
    }
 
    protected override void SetExpandedView()
    {
        //control specific code here 
    }
 
    protected override void HideAll()
    {
        //control specific code here 
    }
}

In the child class we override the abstract methods. Failing to override all the abstract methods on the base class will result in a compile time error unless your child class is also abstract.

That’s really all there is to it. By using this technique I saved having the InitControl() and SetViewMode() methods being implemented with the exact same code in all of my child controls. This would at best have been copy-paste coding which is horrible and to be avoided at all times. A bug in one of those methods would have resulted in needing to update all the implementations to fix it. Add the complexity of working in a team and another team member may not realise that the code is repeated in multiple controls. By using the abstract class there is only one implementation to maintain making maintenance much simpler while allowing a much more object oriented design.

More info on MSDN

If you’re using a Repeater control and have a requirement to have radio buttons in the repeated rows you may find yourself in a head scratching mess. You may find that checking one radio button does not result in all other buttons being unchecked. The radio buttons will essentially start to behave like a bunch of check boxes … not cool.

With normal html radio buttons we group them together using the ‘name’ attribute. All radio buttons with the same value in the name attribute become mutually exclusive resulting in the familiar behaviour where only one radio button in that group can be checked at any one time. In an asp:RadioButton control the name attribute maps to the GroupName parameter which normally works fine.

Things start to go astray when the radio buttons are added to a repeater however. You may be aware that asp.net will insert its own unique id for each control which is not the same as the id you originally gave it in code or markup. It does this to ensure that any elements that have the same id end up with a unique id once rendered. In the case of the repeater this is very necessary as you are taking the same elements with the same id and emitting them multiple times. Unfortunately a repeater also mangles the name attribute of the controls. Normally this can be safely ignored but radio buttons rely on this attribute to work out which group they belong to. All of a sudden each radio button belongs to its own little group and so we end up with check box behaviour.

This is a known issue explained in detail here, however, Microsoft have not yet fixed this and give no indication of if or when it will be fixed.

So now what? Well … there are a couple of work-arounds, none of which are particularly elegant.

1) Avoid using the repeater or radio buttons and see if you can solve the problem with other controls.

2) If you’re stuck with repeaters and radio buttons the most elegant solution is to use javascript to de-select other radio buttons using the click event.

This goes in the <head> tag …

 
 //I use jquery to make life easier but you don't have to 
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js"></script> 
 
<script type="text/javascript">
    function MakeRbExclusive(rb) {
        var rbs = $('#rbData :radio');
        for (var i = 0; i < rbs.length; i++) {
            if (rbs[i] != rb) rbs[i].checked = false;
        }
    }
</script>

And our repeater …

<div id="rbData">
    <asp:Repeater ID="repeater" runat="server">
        <ItemTemplate>
            <!-- I have bound to simple Dictionary<string, string> created in page load for example purposes -->
            <asp:Label ID="lbl" runat="server" AssociatedControlID="radio"><%#Eval("key")%></asp:Label>
            <asp:radioButton ID="radio" runat="server" value=<%#Eval("value")%> onclick="MakeRbExclusive(this);"/>
            <br />
        </ItemTemplate>
    </asp:Repeater>
</div>

3) Avoid the use of a repeater completely and add your controls dynamically from code behind in a loop to achieve the same result. I *really* don’t recommend this. It is finicky at best and takes very careful coding. Dynamically added controls are not automatically tracked in viewstate and can create big problems if not carefully coded. I have had to do this in the past but it is definitely an option I’d only consider once I have exhausted all others.

Happy coding!

We are often required to implement the singleton pattern in our code. While doing this yet again I thought there must be a generic way to do this and I came up with the following code …

public static class Singleton<T> where T : class, new()
{
   private static volatile T _instance;
   private readonly static object _lockObj = new object();
 
   public static T Instance
   {
       get
       {
           if (_instance == null)
              lock (_lockObj) if (_instance == null) _instance = new T();
 
           return _instance;
       }
  }
}

This allows you to use any class as a singleton …

var mySingleton = GenericSingleton<MySingleton>().Instance;

It’s not perfect … there is nothing stopping the developer from creating a new instance of the class which breaks the singleton pattern. Doing it the normal way makes it impossible to create more than one instance of a class but this way allows the flexibility to use a class as a singleton even if it’s not implemented that way and also allows a mix of singleton and instances of the same class.

In any event it makes interesting use of generics and I just thought it was cool so I thought I’d share

Viewstate is often touted to be heavy and slow and better off disabled in most aspx applications. When used properly veiwstate can be quite a useful tool with not too much overhead. Use it improperly and all the horror stories you’ve heard start to come true …

If you view page source in an aspx application that has viewstate enabled site wide you will see the hidden __VIEWSTATE field will have a long encoded string of data. This is quite heavy and takes some time to trasmit betweeen the server and client. Our aim is to minimise the length of this data load to the point where overhead is no longer a concern.

First of all viewstate is enabled by default across the entire project so the first thing we need to do is turn it off. The idea is to opt in to viewstate rather than opt out. We only want to turn it on for the controls where we specifically want to maintain state.

In each masterpage or at the top of each page you can place this code in the page directive to disable the viewstate.

<%@ Page EnableViewState="False"  ViewStateMode="Disabled"%>

Or you can disable the viewstate across the whole application by putting this in the Pages tag in web config.

<Pages EnableViewState="false"  />

Now that Viewstate is off by default … we can choose which controls we want to maintain state for. Most text fields and simple controls will be fine without viewstate. As a general rule leave it off until you have a specific reason to turn it on. The give away will be when you try to access the value of a control in code behind and get the default value no matter what value was set. In this case its time to turn on viewstate for that control only. We do this by using the same code as we did to turn it off …

<asp:DropDownList runat="server" ID="myDdl" EnableViewState="True"  ViewStateMode="Enabled"/>

You can add this to any control and access its value from a postback. If you view the page source again you will see the __VIEWSTATE field is much smaller … naturally the larger number of controls you enable viewstate for the larger the field will be.

Use it with caution but don’t write it off as bad practice.

All over the web I see the code you see below. While it will work it is wrong … don’t do it! A web response stream is a stream like any other, you need to ensure that it is closed when you are finished with it or it will not release its resources. In the case of a web response (or request for that matter), failing to close it could mean the server will run out of connections. In a high traffic web site this won’t take all that long.

Let’s take a look at the code … what would happen if the call to Write throws an exception? Execution would stop right there and the exception will get bubbled up the call stack. The call to Close will never happen and the response stream will remain open reducing the server’s connection capability by one.

 var responseStream = response.GetResponseStream();
 responseStream.Write(byteData, 0, byteData.Length);
 responseStream.Close();

We can avoid this by putting the call to Close in a finally block as below. This would guarantee that the call to Close will be made even if an exception is thrown. This code is perfectly valid, but cumbersome to have to do every time you need to ensure a resource is released.

var responseStream = response.GetResponseStream();
try
{
    responseStream.Write(byteData, 0, byteData.Length);
}
finally
{
    responseStream.Close();
}

The code can be rewritten as below to produce the same behaviour. The ‘using’ keyword automatically calls Dispose (as good as calling Close) on the resource as soon as it falls out of scope resulting in the same behaviour as our finally block. Any time you use a stream, db connection or any resource that needs to be released, use a ‘using’ statement and you can’t go wrong.

using (var responseStream = response.GetResponseStream())
{
    responseStream.Write(byteData, 0, byteData.Length);
}

I have often wondered about Linq to objects. When we use a linq Select or FirstOrDefault statement what is the complexity of the call? Does it iterate through the entire list until it finds the object it is looking for in which case we are dealing with O(n) complexity? The other day I had to write a small migration tool that answered my question. Linq to objects does in fact iterate through every item in a list until it stumbles across the object it is looking for. Take the following case…

 
private List<int> 
private List<int> list2;
 
Public LinqTester()
{
	Console.WriteLine("Populating lists ...");
	list1= new List<int>();
	list2 = new List<int>();
 
	for(var i = 0; i <= 100000; i++)
	{
		list1.Add(i);
		list2.Add(i);
	}
	list2.Sort();
}
 
public void LoopTest()
{
	Console.Write("Starting loop test ... ");
	var start = DateTime.Now;
	foreach (var num in list1)
	{
		list2.FirstOrDefault(x => x == num);
	}
	var timeTaken = DateTime.Now - start;
	Console.WriteLine(string.Format("Time taken = {0}", timeTaken));
}
 
public void BinaryTest()
{
	Console.Write("Starting binary test ... ");
        var start = DateTime.Now;
	foreach (var num in list1)
	{
		list2.BinarySearch(num);
	}
	var timeTaken = DateTime.Now - start;
	Console.WriteLine(string.Format("Time taken = {0}", timeTaken));
}
 
//output
//Starting loop test ... Time taken = 00:01:16.5160000
//Starting binary test ... Time taken = 00:00:00.0170000

From this simple test we can see that using a binary search is by far more efficient than using linq to objects. When you think about it the compiler has no way of knowing if the list is sorted or how to compare the objects contained in the list if they are objects rather than primitives. It is impossible for the compiler to optimise the search so it can only do a linear search through the collection until it finds the item it is looking for. If you’re dealing with small collections this isn’t an issue but when the collections get large or if you’re concerned about performance then it’s worth considering whether linq is the appropriate choice.

Power Commands is a free and extremely useful plugin for visual studio. Among its many features is ‘Collapse All’ so that you can collapse the solution tree in the solution explorer and ‘Open Command Window’ to open a command window in the directory of the selected project. These are the two features I use the most and prove invaluable as the solution I use at work has 91 projects attached to it … this can be really painful to navigate when a number of the projects are expanded. Well worth the download …

Download Here

We are commonly required to handle comma delimited lists while developing applications. In the past, I have used for loops or Array.Split() to handle these situations. At least I did until I discovered a handy little class in the .NET framework that is there to handle just such situations. The CommaDelimitedStringCollection class in the System.Configuration namespace behaves just like a normal generic list including methods for Add, Remove, IndexOf, Count, etc and can be looped through like any other list. This allows the flexibility of searching and sorting and also simplifies the handling of empty lists and removal of trailing commas when returning the comma delimited string. To convert to the comma delimited string all you have to do is call ToString() and you’re done.

More information can be found here

 
int i = 1;
string str1 = "A String";
string str2 = "Another String";
 
//assume System.Configuration has been imported
CommaDelimitedStringCollection strList = new CommaDelimitedStringCollection();
strList.Add(i.ToString());
strList.Add(str1);
strList.Add(str2);
 
Console.WriteLine("Count = " + strList.Count.ToString()); //output => Count = 3
Console.WriteLine("Index of '1' = " + strList.IndexOf("1")); //output => Index of '1' = 0
Console.WriteLine(strList.ToString());  //output => 1,A String,Another String

Extension methods are a handy feature that allows you to extend the functionality of existing classes for which you do not have the source. Extension methods must be static and the type following the ‘this’ keyword indicates the type that is extended by this method.

More information on extension methods can be found here

These are just some of the extension methods I commonly use to make everyday coding a little easier and more readable.

/// <summary>
/// Reformat a string so that the first letter of every word is capitalised and every other letter is lower case
/// </summary>
/// <param name="str">String to format</param>
/// <returns>Formatted string</returns>
public static string ToTitleCase(this string str)
{
    CultureInfo ci = new CultureInfo("en");
    TextInfo cc = ci.TextInfo;
    return cc.ToTitleCase(str);
}
 
/// <summary>
/// Convert this string to its enum type
/// </summary>
/// <typeparam name="T">Type of enum</typeparam>
/// <param name="enumValue">string value to parse</param>
/// <returns>Enum type parsed from string</returns>
public static T ConvertToEnum<T>(this string enumValue) where T : struct
{
     if (!typeof(T).IsEnum) throw new InvalidEnumArgumentException("T must be an enum");
     return (T)Enum.Parse(typeof(T), enumValue, true);
}
 
/// <summary>
/// Get the value of a table column from a reader object
/// </summary>
/// <typeparam name="T">Type  of expected return value</typeparam>
/// <param name="reader">Reader oject to get the value from</param>
/// <param name="columnName">Name of column to retrieve the value from</param>
/// <returns>Column Value</returns>
/// <exception cref="NullReferenceException">If T is not nullable and the column value is null</exception>
public static T GetColumnValue<T>(this IDataReader reader, string columnName)
{
       if (reader.IsDBNull(reader.GetOrdinal(columnName)))
       {
           if (
               (typeof(T).IsGenericType && typeof(T).GetGenericTypeDefinition() == typeof(Nullable<>))
               || typeof(T) == typeof(string)
              )
           {
               return default(T);
           }
           else throw new NullReferenceException("DB Value is null");
       }
       else return (T)reader[columnName];
 }
 
//The above methods are called like this ...
string myStr ="exAmple sTrinG";
Console.WriteLine(myStr.ToTitleCase()); //Output --> Example String
 
//assume we have the namespace Microsoft.SqlServer.Management.Smo imported
string varChar = "VarChar";
SqlDataType testVrChr = varChar.ConvertToEnum<SqlDataType>();
 
//where reader is an IDataReader
int? value = reader.GetColumnValue<int?>("ColName");

Using background threads to handle long running processes such as fetching data from the db should be common practice when developing windows forms. Failure to do so will result in a clunky UI that will lock up and may appear as crashed to the user. It also allows you to do nice things like updating progress bars etc.

A common trap is trying to call a method which updates a UI control from a background thread. This will result in the “Cross Thread Call” exception which can frighten many developers away from threading in the IU. Here is a pattern I tend to follow when threading UI that takes a lot of the mystery out of things and keeps the UI running smoothly.

First we have a method that calls a long running process. In this method we simply create a new thread in which to run the process and get it started.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/// <summary>
/// Do some long running process on a background thread
/// </summary>
private void Start()
{
     lbl.Text = string.Empty;
     Thread worker = new Thread(DoSomething);
     worker.Start();
}
 
/// <summary>
/// Long running process 
/// </summary>
private void DoSomething()
{
     for (int i = 0; i <= 100; i+=5)
     {
          UpdateProgressBar(i);
          Thread.Sleep(500);   
     }
}

In each iteration of the loop we update the value of a progress bar. This however can only be achieved on the UI thread and this method was called on the background thread. Normally this would throw an exception as the invoke keyword is not used but because of the way the UpdateProgressBar method has been written this is not an issue.

The code below shows how to write any method that updates a UI control so that it can be called safely from any thread and will always execute on the UI thread no matter what the thread the caller is on.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

/// <summary>
/// Something that updates a UI control that 
/// might be called from a background thread 
/// </summary>
/// <param name="progress"></param>
private void UpdateProgressBar(int progress)
{
     //Wrap any code that updates a UI control in this anonymous delegate
     Func<int, object> work = delegate(int progressCount)
     {
        if (progressCount < 0) progressCount = 0;
        if (progressCount > 100) progressCount = 100;
        progressBar1.Value = progressCount;
        if (progressCount == 100) lbl.Text = "Done!";
        return null;
     };
 
     //Check if we are running on a background thread and if so use Invoke
     //otherwise just call the delegate
     if (this.InvokeRequired) Invoke(work, progress);
     else work(progress);
}

The Func is an anonymous delegate … all logic that affects controls should be wrapped in this. The last two lines handle the differing threads. InvokeRequired determines if we are on the UI thread or the background thread. If we are on a background thread it will return true and we call Invoke on the anonymous method to ensure it is executed on the UI thread. If we are already on the UI thread the method is just called without Invoke.

By structuring the control update methods this way they can be called from any thread and will never throw an error due to cross thread calls.