Donkblog : .NET

A little early, but who is keeping score? Timers!

Brandon Turner — Mon, 28 Apr 2008 18:03:37 GMT

I ran into a problem the other day at work where I had put in an assert to verify that a timer I was using was not being called back too early. The timer interval was adjusted depending on user interaction and I just wanted to make sure interval was always being set correctly.

For the most part everything was fine, however I started to get reports that the assert started to show up every once and a while. I ended up removing the assert because the callback time and the expected callback time were so close it didn’t matter in my case.

This intrigued me though. So I wrote a little test program to make sure that it wasn’t a problem with my code, and I copied the relevant part of the that test application here:

DateTime _startTime;
Timer _currentTimer;
private void button1_Click(object sender, EventArgs e)
{
    StartTimer();
}

public void StartTimer()
{
    _currentTimer = new Timer();
    _startTime = DateTime.Now;
    _currentTimer.Interval = 1000;
    _currentTimer.Tick += new EventHandler(t_Tick);
    _currentTimer.Start();
}

void t_Tick(object sender, EventArgs e)
{
    // What time is it now?
    DateTime now = DateTime.Now;

    // Add the interval to the time when we started the timer, 
    // this is the earliest possible
    // time we should be called back
    DateTime minCallbackTime = _startTime.AddMilliseconds(1000);

    // Check to see if the time we though was 
    // first possible to call back is greater then
    // the current time we were called back to make 
    // sure it isnt in the future.
    if (minCallbackTime > now)
    {
        String output = String.Format("The minimum callback time was {0} but the current time is {1} with a total difference of {2}", 
                                       minCallbackTime, 
                                       now, 
                                       minCallbackTime.Subtract(now).TotalMilliseconds);
        Debug.WriteLine(output);
    }
    else
    {
        Debug.WriteLine("All is quiet on the western front.");
    }

    _currentTimer.Dispose();

    // Start the process again
    StartTimer();
}

The log looked like:

The minimum callback time was 4/27/2008 5:09:21 PM but the current time is 4/27/2008 5:09:21 PM with a total difference of 2.9935
The minimum callback time was 4/27/2008 5:09:22 PM but the current time is 4/27/2008 5:09:22 PM with a total difference of 1.0405
All is quiet on the western front.
All is quiet on the western front.
The minimum callback time was 4/27/2008 5:09:25 PM but the current time is 4/27/2008 5:09:25 PM with a total difference of 10.8055
The minimum callback time was 4/27/2008 5:09:26 PM but the current time is 4/27/2008 5:09:26 PM with a total difference of 0.064
The minimum callback time was 4/27/2008 5:09:27 PM but the current time is 4/27/2008 5:09:27 PM with a total difference of 1.0405

Assembly Version - Odds and Ends

Brandon Turner — Tue, 11 Mar 2008 17:16:12 GMT

What's the Assembly Version Good For?

Using assembly version is a wonderful way for someone to help maintain and support their applications. It is defined in the AssemblyInfo.cs file through an attribute. You can manually update it or have a auto incrementing process to control your assembly version. It is a good idea to display it on an 'About Dialog' so users can report it when they suggest new features or find bugs.

How Do I Retrieve the Assembly Version?

From a console application the version number can be retrieved by:

System.Reflection.Assembly.GetExecutingAssembly().GetName().Version

And from an application that loads the System.Windows.Forms library it can by retrieved by:

new Version(Application.ProductVersion)

Both of these calls will take about 10ms to run the first time, but the results will be cached for future calls.

Tell Me Something Weird!

If you don't define an assembly version the first method will return 0.0.0.0 and the 2nd method will return 1.0.0.0.

Lazy Loading for the Lazy Coder

Brandon Turner — Fri, 07 Mar 2008 18:08:03 GMT

Lazy loading in properties is very common. It is a relativity simple concept of only loading the data you once you actually need it, instead of front loading it all. Though the problem with doing this all over the place is that you end up copying and pasting code a lot to do it. And we all know how much copying and pasting code can lead to bugs and convoluted code.

In order to allow for the benefits of lazy loading but also to make the code a bit cleaner I made a class to help with it. The class is slightly under developed in the fact that it can't be used in all cases, but it is more a proof of concept of what can be done to help. As I use the class more and need it to do more things I'm sure I will expand it and adapt it to my needs. I strongly encourage everyone to see if something like this could help their code.

Below I have the code for the class. Then following that is code to show an example of code that doesn't use it and the same code that does use it.

public class LazyLoader<T>
{
    public delegate T LazyLoaderDelegate();
    private bool? isInit = null;
    private T _value;
    private LazyLoaderDelegate _valueCalculator;

    public LazyLoader(LazyLoaderDelegate valueCalculator)
    {
        _valueCalculator = valueCalculator;
    }

    public T Value
    {
        get
        {
            if (isInit != true)
            {
                _value = _valueCalculator();
                isInit = true;
            }
            return _value;
        }
        set
        {
            _value = value;
            isInit = true;
        }
    }

    public void Clear()
    {
        isInit = false;
    }

}

Code that doesn't use the lazy loading class:

public class WidgetCounter
{
    private int _numberOfWidgets;
    private bool _numberOfWidgetsInit;
    public int NumberOfWidgets 
    {
        get
        {
            if (_numberOfWidgetsInit == false)
            {
                _numberOfWidgets = GetValue();
            }
            return _numberOfWidgets;
        }
        set
        {
            _numberOfWidgets = value;
            _numberOfWidgetsInit = true;
        }
    }

    private int GetValue()
    {
        // Do some really time consuming operation
        Thread.Sleep(1000);
        return 5;
    }

}

Code uses the lazy loading class:

public class WidgetCounter
{
    private LazyLoader<int> _numberOfWidgets;

    public WidgetCounter()
    {
        _numberOfWidgets = new LazyLoader<int>(delegate { return GetValue(); });
    }
    public int NumberOfWidgets
    {
        get { return _numberOfWidgets.Value; }
        set { _numberOfWidgets = value; }
    }

    private int GetValue()
    {
        // Do some really time consuming operation
        Thread.Sleep(1000);
        return 5;
    }

}

The Dangers Of Exception Based Logic Part 1 - Parsing Integers

Brandon Turner — Mon, 03 Mar 2008 17:59:51 GMT

Exception based logic is one of those things that actually makes me cringe when I see it. Often times it is really easy to avoid like in the case below. Believe it or not, exceptions in .NET aren't cheap and shouldn't be taken for granted.

Exception Based Logic: 14-19ms

Try Function Based Logic: 0ms

static void Main(string[] args)
{
    using (new QuickTimer("Exception Based Logic"))
    {
         for (int i = 0; i < 10; i++)
         {
             try
             {
                 int j = Int32.Parse("a");
             } catch (Exception ex)
             {
                 Console.WriteLine("Error");
             }
         }
    }

    using (new QuickTimer("Try Function Based Logic"))
    {
         for (int i = 0; i < 10; i++)
         {
              int j = 0;
              if (!Int32.TryParse("a",out j))
              {
                  Console.WriteLine("Error");
              }
         }
      }
}