iMakeDecisions is launched

I feel bad about not mentioning this earlier.  Some of my buddies from MobileDataForce just launched their first IPhone application: IMakeDecisions.

www.iMakeDecisions.com

Description from the site:

Let iMakeDecisions help you choose where to dine, decide when your product should launch, pick the color of your bridesmaids’ dresses, determine who should pick up the tab, select the name for your child, choose which movie to watch, pick your mood for the day, determine the value of your house, accept or reject the job offer, turn left or right, pick a new hairstyle, determine if a country has weapons of mass destruction, choose your college major, create your stock portfolio, pick your vice presidential running mate, determine guilt or innocence, select who to fire or hire, clarify your love life and/or select a candidate. iMakeDecisions can make all those decisions and more! Imagine having a decision-free life both personally and professionally.

INETA Community Champion

I'm not bragging (really, I'm not), I'm just posting information...about me...winning an award.  Crap, that is bragging isn't it.  Oh well, the show must go on.

I'm an INETA Community Champion for 2nd Quarter 2008.

You can read more about what it take to become a Community Champion at INETA's web site (see link above).

On the Alt.Net Podcast

This post is a bit late, but I thought I should mention that I'm on the Alt.Net Podcast talking about JQuery in ASP.Net with Rick Strahl, Dave Ward, Bertrand Le Roy, Scott Koon, and Steven Harman.

This was a fun podcast to be on, even though we had a few hick-ups along the way (I kept disconnecting -- thank you Skype and Steve's hard drive crashed).  But having Rick Strahl and Dave Ward there was great (if you like JQuery and work on ASP.Net, you need to read their blogs). 

But having Bertrand there was absolutely wonderful.  Bertrand is a Microsoft employee that was there for the conversations that led to the JQuery announcement.

Mike Moore is doing an excellent job on these.  If you haven't seen this podcast before, I highly recommend it.

http://altnetpodcast.com/episodes/11-jquery-in-asp.net

LINQ in Depth: Understanding ToArray()

In my last post, I showed a bit of code that would take any list, array, diction, or IEnumerable implementer, and return a delimited string.

My solution created a StringBuilder, then looped thru the list, adding the values to the StringBuilder each time.  Then, finishing up, remove the last delimiter.

The other solution is to use the LINQ ToArray method, the pass the result to String.Join. 

You can see the code for both extension methods below.

   1: public static class Extensions

   2: {

   3:     public static string ToDelimitedString<T>(this IEnumerable<T> list, string delimiter, Func<T, string> action)

   4:     {

   5:         var sb = new StringBuilder();

   6:  

   7:         foreach (T t in list)

   8:         {

   9:             sb.Append(action.Invoke(t));

  10:             sb.Append(delimiter);

  11:         }

  12:         sb.Remove(sb.Length - delimiter.Length, 1);

  13:         return sb.ToString();

  14:     }

  15:  

  16:     public static string ToDelimitedString2<T>(this IEnumerable<T> list, string delimiter, Func<T, string> action)

  17:     {

  18:         return string.Join( delimiter, list.Select( action ).ToArray() );

  19:     }

  20:  

Next I thought it would be interesting to see what the ToArray was actually doing.  ToArray is a Linq function that converts anything that inherits from IEnumerable to an array.

An IEnumerable is a list of undetermined length, and an array has a definite length, so there has to be some sort of reallocation going on.  Enter Reflector (now a RedGate product), with Reflector you can select a method and hit Disassemble to inspect the innards.  When looking for LINQ methods, you look in the dll System.Core.  Below is what you will find.

   1: public static TSource[] ToArray<TSource>(this IEnumerable<TSource> source)

   2: {

   3:    if (source == null)

   4:    {

   5:       throw Error.ArgumentNull("source");

   6:    }

   7:    Buffer<TSource> buffer = new Buffer<TSource>(source);

   8:    return buffer.ToArray();

   9: }

The interesting part is the Buffer class -- sorry, struct -- which is an internal object.  When you start browsing the .Net Framework you will see lots of internal objects running around, some useful, some not.  You get used to it.

Anyway, you can see below that Buffer creates an array, then loops though the source object (an IEnumerable of something), adding elements to the array.  If the array runs out of space, a new array is created that is double the size of the original array (note that the initial array size is 4). This is standard collection behavior as well, you can look it up in the generic List.

   1: internal struct Buffer<TElement>

   2: {

   3:    internal TElement[] items;

   4:    internal int count;

   5:    internal Buffer(IEnumerable<TElement> source)

   6:    {

   7:       TElement[] array = null;

   8:       int length = 0;

   9:       ICollection<TElement> is2 = source as ICollection<TElement>;

  10:       if (is2 != null)

  11:       {

  12:          length = is2.Count;

  13:          if (length > 0)

  14:          {

  15:             array = new TElement[length];

  16:             is2.CopyTo(array, 0);

  17:          }

  18:       }

  19:       else

  20:       {

  21:          foreach (TElement local in source)

  22:          {

  23:             if (array == null)

  24:             {

  25:                array = new TElement[4];

  26:             }

  27:             else if (array.Length == length)

  28:             {

  29:                TElement[] destinationArray = new TElement[length * 2];

  30:                Array.Copy(array, 0, destinationArray, 0, length);

  31:                array = destinationArray;

  32:             }

  33:             array[length] = local;

  34:             length++;

  35:          }

  36:       }

  37:       this.items = array;

  38:       this.count = length;

  39:    }

  40:  

  41:    internal TElement[] ToArray()

  42:    {

  43:       if (this.count == 0)

  44:       {

  45:          return new TElement[0];

  46:       }

  47:       if (this.items.Length == this.count)

  48:       {

  49:          return this.items;

  50:       }

  51:       TElement[] destinationArray = new TElement[this.count];

  52:       Array.Copy(this.items, 0, destinationArray, 0, this.count);

  53:       return destinationArray;

  54:    }

  55: }

Now, in spite of the differences between the methods used to return the same results, my initial thought was that there would not be much of a difference, performance wise, in how the code ran.  So to test that theory I ran the following tests.

My tests class create a large string list, which is then handed to each method after it is created.  I used the same string for every item in the list, because uniqueness didn't interest me for this test.  Plus, it limited the size of the lists I could create.  If I used unique strings, the largest list I could create was 8,000,000 before I got out of memory exceptions.  Using the same string I could get 20,000,0000.

   1: [TestFixture]

   2: public class ToDelimitedString_Tests

   3: {

   4:     private List<string> _list;

   5:  

   6:     public ToDelimitedString_Tests()

   7:     {

   8:         int count = 2500000;

   9:         _list = new List<string>( count );

  10:         for (int i = 0; i < count; i++)

  11:         {

  12:             _list.Add( "Item" );

  13:         }

  14:     }

  15:  

  16:     [Test]

  17:     public void ToDelimitedString_Mine()

  18:     {

  19:         string result = _list.ToDelimitedString("----", x=>x);

  20:     }

  21:     [Test]

  22:     public void ToDelimitedString_Theirs()

  23:     {

  24:         string result = _list.ToDelimitedString2("----", x=>x);

  25:     }

  26: }

Below you can see the results (charted and in a table) in seconds.  Smaller numbers are better.

 

	ToDelimitedString	ToDelimitedString2
10,000	0.04	0.04
100,000	0.09	0.07
1,000,000	0.28	0.35
2,500,000	0.65	0.85
5,000,000	1.26	1.81
7,500,000	1.8	2.43
10,000,000	2.52	3.38
20,000,000	5.28	6.72

 

My conclusion from the data: my hypothesis was correct. There is a performance difference between the two methods, and mine does perform better.  Also, as I suspected, there is not a true significant difference between the two methods.  At least for the size of the string lists my current application will handle.  Note that I had to get up to 1 million items before the times even got interesting, and even then everything happened pretty darn quickly. 10,000 items at 0.04 seconds is pretty darn good.  Array sizes below that barely registered.

One interesting note though, I did try to do a profile of the two methods using dotTrace.  When profiling the second method was actually faster than mine -- consistently.  At this point I don't know why that would be.  If you have any ideas please leave me a note.

ToDelimitedString Extension Method

This has probably been done before, but I thought I would post my implementation.

Take a given generic list (or something that implements IEnumerable, and convert it to a delimited string.

First, declare this delegate somewhere:

   1: public delegate string StringValueDelegate<T>(T obj);

 

Next, in a static class, (I have a class called GeneralExtensions for just this sort of thing), add this code.

   1: public static string ToDelimitedString<T>(this IEnumerable<T> list, string delimiter, StringValueDelegate<T> action)

   2: {

   3:     var sb = new System.Text.StringBuilder();

   4:     foreach (var t in list)

   5:     {

   6:         sb.Append(action.Invoke(t));

   7:         sb.Append( delimiter );

   8:     }

   9:     sb.Remove(sb.Length - 1, 1);

  10:  

  11:     return sb.ToString();

  12: }

Now if I have a customer class with a FirstName and LastName properties, like this:

   1: public class Customer

   2: {

   3:    public string Id { get; set; }

   4:    public string FirstName { get; set; }

   5:    public string LastName { get; set; }

   6: }

And I have a list of them, and want to convert them to a coma delimited list, I would do it like this:

   1: var list = new List<Customer>();

   2: list.Add(new Customer { FirstName="Tom", LastName="Bin" });

   3: list.Add(new Customer { FirstName="John", LastName"Doe" });

   4:  

   5: string result = list.ToDelimitedString(",", c => c.FirstName + " " + c.LastName);

The result will look like this: "Tom Bin, John Doe"

Generic C# WinForms

When Generics was first released in .Net 2.0, I was kind of surprised how few built in generic types there were.  A List, a dictionary, a event handler; but not much beyond that.  Nothing like what you see with C++ STL, ATL, or WTL. (turns out there are some reasons for that, C++ Templates can do things that C# Generics just can't).  But no matter, we can invent our own.

In my current desktop app, I have a reoccurring need for an OK/Cancel form.  Plus I had a number of things I wanted preset for me. 

The first problem is working with the Generic portion of the C# language.  I want to be able to create the OK/Cancel form like this:

   1: var dlg = new OkCancelForm<MyDisplayControl>();

   2: if (dlg.ShowModal()== DialogResult.OK)

   3: {

   4:   // do something here...

   5: }

Also, I need to be able to retrieve, or load the user control that is being displayed.  I created a property called DisplayControl.  So now I can load and retrieve values from the display control.  I'll expand my sample:

   1: var dlg = new OkCancelForm<MyDisplayControl>();

   2: dlg.DisplayControl.Data = MyData;  // dlg.DisplayControl will be of type MyDisplayControl

   3:                                    // data is a property of MyDisplayControl

   4: var result = dlg.ShowDialog();

   5: if (result == DialogResult.OK)

   6: {

   7:     var data dlg.DisplayControl.Data; 

   8:     // now do something with the data 

   9: }

OK, so that was how I wanted it to work, now onto some real code.

The Implementation

First thing to do is to just create a new form and call it OkCancelForm.  Put on an OK and cancel button just like you normally would.  For a bit of advice on this: I start with two panels, one on the bottom (containing the OK and Cancel buttons) docked to the bottom.  And the other docked to Fill in the middle.  This will host your custom control.

Now C# creates forms with 2 files, OkCancelForm.cs and OkCancelForm.designer.cs.  We first want to look at the OkCancelForm.cs, and change the class declaration to what you see below:

   1: public partial class OkCancelForm<T>: Form where T: ContainerControl, new()

If you compile after doing that, you will see errors (if you are using ReSharper, you wont even have to compile, you'll just see errors).  Turns out we have to change the other half of the partial file implementation that makes up a WinForms form.  So open up the file named OkCancelForm.designer.cs, and change the declaration to match this:

   1: partial class OkCancelForm<T>

Even though the class names were the same, because one class was a generic class and the other was not, they did not match.

But, diving into the syntax a bit from the first sample.  After the form declaration you see this code: "Form where T: ContainerControl, new()".  This code tells the generic (T) that T must be of type ContainerControl, and must have a default constructor that takes now parameters -- because this class is going to create a new instance of T when OkCancelForm is created.  You can't be passing in stuff through the controls constructor.  It just wont work.

Now for some more changes to OkCancelForm.cs.  Here you can see we are adding InitializeDisplayControl() to create a new copy of the display control, and we have added a property called display control of type T (which must be a ContainerControl, remember).  The other little trick we are doing there is making the control full screen. 

You will also see a reference to displayPanel on like 14.  That is one of the two panels I mentioned previously that is docked to the form in fill mode (the other is docked to the bottom of the form and holds the OK and cancel buttons).

   1: private T _displayControl;

   2: public OkCancelForm()

   3: {

   4:     InitializeComponent();

   5:     InitializeDisplayControl();

   6: }

   7:  

   8: public T DisplayControl { get { return _displayControl;  } }

   9:  

  10: private void InitializeDisplayControl()

  11: {

  12:     _displayControl = new T();

  13:     _displayControl.Dock = DockStyle.Fill;

  14:     displayPanel.Controls.Add(_displayControl);

  15: }

 

That is the basics of what you need.  Still undone in this sample is validation.  But the tricky part (knowing how to make a partial class generic) is pretty well spelled out for you here.

Enjoy.  And if you have any questions, please leave them in the comments.