Programming

Typed Enum Parsing with Generics

Jeff Deville — Sun, 15 Apr 2007 04:21:02 GMT

public static T Parse<T>(string text)
{
    if (!typeof(T).IsEnum)
        throw new ArgumentException(typeof(T) + " is not an Enum");
    try
    {
        return (T)Enum.Parse(typeof(T), text, true);
    }
    catch (Exception)
    {
        return default(T);
    }
}

Not much to show here. I was tired of having to manage all the casting when using the Enum.Parse function. Unfortunately, I was unable to use this check

where T : System.Enum

which would have given a compilation error if you tried to use it to convert a string to an object that wasn't an Enum. Unfortunately, you can't use that as a Type parameter constraint.

Threading: Using Delegates - Part 2

Jeff Deville — Sun, 15 Apr 2007 04:02:27 GMT

In Part 1, we began to examine delegates as they applied to multi-threading scenarios. However, the specific implemenation was not necessarily an optimal one. The strategy implemented was to periodically check to see if the work was completed or not. Once it was, EndInvoke was called, and execution continued. This was a "Daddy, are we there yet?" strategy. It's as annoying in your code as it is in the car. There's a better way. In fact, there are 2.

The first is very simple. EndInvoke will block the calling thread until the work is complete. Let's take another physical world example. Let's assume it's coming up on lunch time, and you and a coworker are going to Chipotle (because there's just no other place you'd ever want to go.) Unfortunately, he's in a meeting that's running long, and you have to get some code finished before you leave. How would this look if it was delegate / asynchronous code?

class TimeForLunch
{
    private delegate void WaitForMeetingToEndHandler();

    static void Main(string[] args)
    {
        WaitForMeetingToEndHandler waitForMeeting = 
            new WaitForMeetingToEndHandler(WaitForMeetingToEnd);

        // Start waiting on your coworker
        IAsyncResult result = waitForMeeting.BeginInvoke(null, null);

        // Keep working on your project
        FinishCode();

        // Check to see if your coworker's meeting is out.  If not, wait until it is.
        waitForMeeting.EndInvoke(result);

        // Both tasks are complete.  It's burrito-time.
        Console.WriteLine("Go to lunch.");

        Console.ReadLine();
    }

    static void WaitForMeetingToEnd()
    {
        Thread.Sleep(10000);
        Console.WriteLine("Meeting ended");
    }

    static void FinishCode()
    {
        Thread.Sleep(1000);
        Console.WriteLine("Code complete");
    }
}

Finally, there is one other strategy to use. Suppose you are working on a customer presentation. You're ready to go, but you can't send it off to the client until your finance department finishes running some numbers for you. You ask them to let you know as soon as that is complete, so you can send off the presentation. The distinction here is that you don't really have any simultaneous work to be doing. You just need to wait on them, and then kick off the email. We'll start with the code:

class Presentation
{
    private delegate DataTable WaitForFinanceHandler();
    static void Main(string[] args)
    {
        Console.WriteLine("Tell Finance to finish, and get back to me.");
        WaitForFinanceHandler waitForFinance = FinishFinanceNumbers;
        Console.WriteLine("When done, take me to the SendEmail function");
        waitForFinance.BeginInvoke(SendEmail, null);
        Console.ReadLine();
    }

    static void SendEmail(IAsyncResult result)
    {
        WaitForFinanceHandler waitForFinance =
            (WaitForFinanceHandler) ((AsyncResult) result).AsyncDelegate;
        DataTable financeResults = waitForFinance.EndInvoke(result);
        Console.WriteLine("Finance Results received, emailing...");
    }

    static DataTable FinishFinanceNumbers()
    {
        Thread.Sleep(2000);
        Console.WriteLine("Finance team finished, returning results");
        return new DataTable();
    }
}

So there are a few minor changes here. First, rather than wait on the worker thread to complete in Main, we've opted to ask the thread to notify us by calling back to a different method, SendEmail. Perhaps you've noticed that Intellisense has indicated 2 parameters to BeginInvoke that we have not previously used when calling BeginInvoke. The first of these is actually another delegate that represents the method to call when the work completes. The signature for this method is hard coded.

void METHOD_NAME(IAsyncResult result)

Things get a bit more complicated here. You see, you need to be able to recover the delegate that you declared in Main, so that you can call EndInvoke (thus getting the function's return value), as we've done in our previous examples. This is a two step process, and it isn't intuitive. The property you are looking for is AsyncDelegate, but the IAsynResult interface does not define it. 2 steps are needed in order to get to your delegate:

1. Add this using statement to your code:

using System.Runtime.Remoting.Messaging;

2. You will need to cast the IAsyncResult to an AsyncResult object. Finally, you will then cast the AsyncDelegate property to a delegate of your type.

WaitForFinanceHandler waitForFinance =
   (WaitForFinanceHandler) ((AsyncResult) result).AsyncDelegate;

Certainly there is a reason for this headache, but with Generics available, I don't see it off the top of my head. At any rate, once you have the original delegate, and the IAsyncResult, you have the same tools as in the previous example. A call to EndInvoke will yield your result.

One last thing. The code above works, but only just barely. Recall that using delegates for asynchronous calls uses the Threadpool behind the scenes. Further, recall that the Threadpool's Threads are all Background threads. Therefore, when the foreground thread (Main) completes, the background thread is killed. So if I had not placed Console.ReadLine() at the very end, the program would have ended without waiting for finance or sending my report at all.

That's it for delegates right now. There are a few more things to learn, but my goal here was not to repeat what I had already read, but to try and present the basic concepts in a manner that was more tangible. If the concepts now make sense, the rest of the articles on the net will hopefully come more naturally.

Threading: Using Delegates - Part 1

Jeff Deville — Sun, 15 Apr 2007 00:12:08 GMT

.Net provides a number of ways to manage threading, and the Internet has no shortage of articles explaining how to use them. Unfortunately, I still found myself having to look up examples every time I was going to use threads of any sort. The information wasn't sticking, because I didn't fundamentally understand what was going on. The goal of this is to present the technology in a more intuitive way.

As mentioned, there are a number of ways to handle threading in .net. I'll hopefully get to all of them in time, but I'm starting with delegates for two reasons:

They're used heavily throughout the framework
They're one of the most confusing concepts.

Before I get started, make sure you're comfortable with what a thread is. A brief google search led me to a decent article on this here. The following two terms are also critical to understanding the rest of the post.

ThreadPool - Threads are fairly expensive to create and destroy. You also need to be careful that you don't spawn too many at a time, because CPU time is consumed when switching between one thread and another. As a result, the CLR manages a pool of threads for you. This allows you to queue as much work as you want, trusting the CLR to manage things efficiently for you.
Delegates - It's easy to be mystified by how delegates work, because so much is done for you by the compiler behind the scenes. To briefly summarize:
- A delegate is often described as a function pointer, a variable that represents a function. This is a true, but not entirely incomplete description.
- Delegates are classes that inherit from System.MulticastDelegate.

It may help to think of your delegate declaration as being very similar to defining a variable of a generic class. (eg: Delegate<RETURNTYPE, ARG1, ARG2> myDelegate). The syntactic help you get is really smoke and mirrors provided by the compiler.

private delegate void MyDelegateType(object message);        
static void Main(string[] args)
{
    MyDelegateType myDelegateVariable = 
       new MyDelegateType(PrintToConsole.Print);

    // The following two lines do the exact same thing
    myDelegateVariable.Invoke("Hello");
    myDelegateVariable("Hello");
}

Using Delegates for Asynchronous Execution

The BeginInvoke / EndInvoke pattern is repeated throughout the framework, so it's a good idea to at least understand this one, even if it doesn't wind up being your preferred strategy.

Using BeginInvoke and EndInvoke follows a similar process to what happens when you go out to eat. Lets introduce our characters:

Customer - Our hapless calling method. Likes steak.
Waitress - Our asynchronous delegate.
Cook - Our easily disgruntled, time consuming worker method.

Now, briefly consider what would happen if this process was a synchronous one. Our customer comes in and orders food, but then, rather than talking on their cell at an obscene volume, or making decidedly half-hearted attempts to control their kids, they just freeze. They don't move, they don't speak. It's a peaceful place, and it makes the waitress' job easier, because all she has to do is bring the order to the cook. There will be no need for breadsticks, or drink refills. The cook takes the order, and begins working on the food. It's done when it's done. There's no hurry, and no complaint. The cook makes the food, and puts it up when he's good and ready. Our waitress immediately snatches it up, and brings it to the customer, who all of the sudden wakes up and begins eating, thinking how fast the service here is.

This is how most of our code generally operates. Generally, it makes sense to work in this way. In this case it doesn't. Below is code that works in a manner more consistent with your past restaurant experiences. Take a look at the Console statements, as I'm trying to equate the code to the restaurant scenario.

public class Cook
{
    static internal Dinner Make(Order order)
    {
        Console.WriteLine("\tCook: Start Cooking... " + order.foodOrder);
        Thread.Sleep(5000);
        if (order.customer.IsAnnoying)
            Console.WriteLine("\tCook: Applying special sauce...");
        return new Dinner();
    }
}
class RestaurantProgram
{
    private delegate Dinner WaitressHandler(Order order);
    static void Main(string[] args)
    {
        Console.WriteLine("Customer enters the restaurant"); 
        Customer customer = new Customer();

        Console.WriteLine("A waitress comes over to take the customer's order.");            
        WaitressHandler customersWaitress = new WaitressHandler(Cook.Make);

        Console.WriteLine("Customer: I'd like the steak and potatoes please.");            
        Order order = new Order("Steak and Potatoes", customer);

        Console.WriteLine("Waitress takes your order, and brings it to the cook.");
        IAsyncResult result = customersWaitress.BeginInvoke(order, null, null);

        int numMinutesWaited = 0;  // minutes = seconds...
        while(!result.IsCompleted)
        {
            if (numMinutesWaited == 0)
                Console.WriteLine("Customer commences people-watching.  Drips salsa all over the table.");

            else if(numMinutesWaited == 1)
                Console.WriteLine("Customer is out of chips, running short of patience.");

            else if (numMinutesWaited == 2)
            {
                Console.WriteLine("Customer complains about the wait...  such a bad idea.");
                customer.IsAnnoying = true;
            }

            numMinutesWaited += 1;
            Thread.Sleep(1000);
        }

        Console.WriteLine("Food is prepared, and the waitress brings it to the customer");
        Dinner dinner = customersWaitress.EndInvoke(result);

        Console.ReadLine();
    }
}

And the output:

Ok, let's take a look at what our waitress is doing. First, she takes the order, using BeginInvoke. Using this method places the customer's order in a queue (ThreadPool) for the cook. You can think of this as the cook's grill. He can only cook so many things at a time.

What is that IAsyncResult object? This object helps us keep track of the cook's progress. In this code, we check the IsCompleted property to see if the food is ready. As you can see, every second of delay increases our customer's agitation. Eventually, IsComplete will be true, meaning that dinner is ready. When this happens, we fall out of the while loop, and the waitress bring our customer's food over with the EndInvoke method. The result object we pass in to EndInvoke is akin to the tickets you see posted over a completed meal on the Ready counter. It's what tells our waittress whose dinner has just been finished, which allows her to determine which customer it belongs to.

Hopefully, this analogy helps explain what delegate are for, and provides some insight into how they work. I'll go over alternative ways to handle your asynchronous code with delegates in Part 2.

Threading: Lock == Monitor

Jeff Deville — Sat, 14 Apr 2007 19:02:59 GMT

The lock statement compiles down to the static Monitor class. In other words:

lock([SOME OBJECT])
{
  // execute code
}

.. is equivalent to

Monitor.Enter([SOME OBJECT])
try
{
  // execute code
}
finally
{
  Monitor.Exit([SOME OBJECT]);
}

The monitor class provides more detailed control, but it's useful to know that for simple cases like the one above, they amount to the same thing.

Threading: Foreground vs Background

Jeff Deville — Sat, 14 Apr 2007 19:02:29 GMT

So I just had a very VERY difficult phone screen the other day. It was a great experience though, because it's pointed me in the direction of a number of important topics that I'm weak on. So this will be a series on those topics. Hopefully round 2 will go a little smoother. :-)

At any rate, my first topic is threading. I took an Operating Systems class in school, but it was

In C
Longer ago than I like to consider.

Definitely time to update my knowledge in this area

Foreground / Background Threads - What's the Difference?:

The CLR doesn't close your program until all the foreground threads have ended. On the other hand, background threads are viewed as only having relevance while foreground threads are running. As a result, when the foreground threads end, your program ends. The CLR will kill any background threads that were executing as necessary. What's the code distinction?

[THREAD].IsBackground = true;

To illustrate, below is a heavily plagiarized code snippet from Pro C# with .Net 3.0 Primer, (page 467).

static void Main(string[] args)
{
   Thread bgroundThread = 
     new Thread(new ThreadStart(SomeFunction));
   bgroundThread.IsBackground = true;
   bgroundThread.Start();
}

Because bgroundThread is a background thread, this console application will end immediately, and whatever you have called in SomeFunction will not be executed. By default, threads are created as foreground threads, so commenting out the IsBackground = true; line will mean the console application doesn't end until SomeFunction completes its work and returns.

What about the ThreadPool / BeginInvoke?

Threadpool threads are background threads, which is the opposite of the behavior you can expect from generating the Thread yourself. Further, it's important to realize that when you create a delegate, and use BeginInvoke, you are not creating a thread, but queueing the work on the thread pool, which again means you're running on a background thread.

Visual Studio 2005 Snippet Editor

Jeff Deville — Fri, 13 Apr 2007 14:47:38 GMT

Tim Heuer, as usual, is putting me in the know. It appears that my complaint regarding Visual Studio's lack of a code snippet editor is being rectified by the community. Check out:

Snippy

A quick note on installation: No shortcuts are placed anywhere, and by default the program files are installed to: C:\Program Files\PowerToys for Visual Studio 8\Snippy. If you'd like to be able to launch this from within Visual Studio, you can do so easily:

In VS2005, Tools >> External Tools
Click Add
Title: Snippy (or whatever you want)
Command: C:\Program Files\PowerToys for Visual Studio 8\Snippy\Snippy.exe
Click Ok

Unfortunately, it doesn't yet seem to know where your Code Snippets directory is to help you out w/ opening and saving, and I couldn't pass that directory in as an Argument or an Initial Directory.

Making the Generic Collections' delegate-based functions more useful

Jeff Deville — Wed, 11 Apr 2007 05:23:20 GMT

.Net 2.0's new generic collections are easy to love. In addition to helping you easily eliminate boxing issues, they've also been bequeathed with some clever delegate-based find and action capabilities. For instance, suppose you have a string collection, and want to implement a way to only pull values from that collection that start with a certain letter. It won't take you much googling to come up with a solution that uses the Predicate<> delegate and looks something like this:

public class StupidSearchMethod
{
    static List<string> names = new List<string>(
            new string[] { "Jeff", "Tara", "Joe" });
    [STAThread]
    public static void Main()
    {
        List<string> namesThatStartWithJ = 
            names.FindAll(NameStartsWithJ);
        foreach (string s in namesThatStartWithJ)
            Console.WriteLine(s);
        Console.ReadLine();
    }

    private static bool NameStartsWithJ(string input)
    {
        return input.StartsWith("J");
    }
}

Output:

Well that's ok, but am I really going to have to write a new search method when I want to find the strings that start with 'T'? It would seem so at first glance, because I am not allowed to pass any information into my predicate to help my search method. Fortunately, this is a pretty simple search, and would be amenable to using an anonymous method:

public class AnonymousSearchMethod
{
    static List<string> names = new List<string>(
            new string[] { "Jeff", "Tara", "Joe" });

    [STAThread]
    public static void Main()
    {
        List<string> namesThatStartWithJ = names.FindAll(
            delegate(string input) { return input.StartsWith("J"); });

        Console.WriteLine("Names that start with 'J':");
        foreach (string s in namesThatStartWithJ)
            Console.WriteLine("\t" + s);

        List<string> namesThatStartWithT = names.FindAll(
            delegate(string input) { return input.StartsWith("T"); });

        Console.WriteLine("Names that start with 'T':");
        foreach (string s in namesThatStartWithT)
            Console.WriteLine("\t" + s);
        Console.ReadLine();
    }
}

Output:

But what if my search logic was not so trivial that I could afford to duplicate it over and over? Suppose I am looking for strings that start with a certain letter, but also have two or more vowels? Now I really need to be able to pass in extra parameters, or I'm going to just have to give up on this entirely, and code my own method. Fortunately, I can combine a more flexible search method with anonymous methods to get what I want.

public class AnonymousPlusComplexSearchMethod
{
    static List<string> names = new List<string>(
            new string[] { "Jeff", "Tara", "Joe" });

    [STAThread]
    public static void Main()
    {
        List<string> results = names.FindAll(
            delegate(string input)
                {
                    return CheckStartLetterAndNumVowels(input, "J", 2);
                });

        // Show Results         Console.WriteLine("Start with 'J' and have 2 vowels:");
        foreach (string s in results)
            Console.WriteLine("\t" + s);
        Console.ReadLine();
    }

    private static List<char> vowels = new List<char>(
            new char[] { 'a', 'e', 'i', 'o', 'u' });
    private static bool CheckStartLetterAndNumVowels(
        string input, string startLetter, int numVowels)
    {
        if (!input.StartsWith(startLetter))
            return false;

        for (int i = 0; i < input.Length; i++)
            if (vowels.Contains(input[i]))
                numVowels--;

        return numVowels == 0;
    }
}

This strategy can be used with the Action<> delegates, like ForEach(Action<>) as well.

More ReSharper Live Templates

Jeff Deville — Tue, 10 Apr 2007 00:11:08 GMT

So just dump mode now because these snippets are a bit random. First the download link again: Live Templates Download

NUnit / MbUnit

test - for some reason, I don't have this snippet using VS, but it was so easy to just create one, I didn't bother digging around to figure out where it was

[Test]
public void $METHOD$Test()
{
    $END$
}

teste - Yeah so I probably could have named this something else, but I just didn't care enough. :-)

[Test,ExpectedException(typeof($EXCEPTION$))]
public void $METHOD$_Exception_Test()
{
    $END$
}

Properties

propcint - Create an int property that looks for it's value from app/web.config before using a default value.

private int _$PROPVAR$ = $DEFAULT$;
public int $PROPNAME$
{
    get
    {
     if (!string.IsNullOrEmpty(
         ConfigurationManager.AppSettings["$CLASSNAME$_$PROPNAME$"]))
        _$PROPVAR$ = Convert.ToInt32(
           ConfigurationManager.AppSettings["$CLASSNAME$_$PROPNAME$"]);
     return _$PROPVAR$;
    }
    set { _$PROPVAR$ = value; }
}

LLBL - Adapter

ec - Create an entity collection. This is pretty simple, but I find that the only drawback to using llblgen is that I tend to have fairly long type names.

EntityCollection<$Type$> $varname$ = new EntityCollection<$Type$>();

llu - Creates a DataAccessAdapter inside of a using block.

using(DataAccessAdapter adapter = new DataAccessAdapter())
{
     $END$
}

ReSharper Live Templates (Code Snippets) - Singleton

Jeff Deville — Mon, 09 Apr 2007 22:58:09 GMT

I'll be posting a series of Live Templates I've created, as JetBrains has not yet created a community site where we can share and import directly from Visual Studio yet. (hint, hint).

Singleton

First a quick note. The obvious way to implement singletons in c# is not thread safe:

public sealed class Singleton
{
    static Singleton instance=null;

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            if (instance==null)
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
}

For an excellent discussion on the topic, read Jon Skeet

I based my template on his solution 4:

public sealed class Singleton
{
    static readonly Singleton instance=new Singleton();

    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    static Singleton()
    {
    }

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            return instance;
        }
    }
}

This, and my other currently used Live Templates can be had here (right click, Save): Live Templates Download

#region Singleton

private static readonly $ClassName$ _instance = new $ClassName$();

static $ClassName$(){}
private $ClassName$(){}

public static $ClassName$ Instance
{
    get { return _instance; }
}

#endregion