I had posted previously that I don't like lamda in C#. The reason is that C# had a different nature before. This is drastically changing and soon we'll have huge amounts of code having lambda and other cool new shiny language features which'll make it alien to a large part of its user base. People are already putting up samples that use code as follows

static void Main(string[] args)
{
    (Printer())(42);
}

static Action Printer()
{
    return (T t) =>
              {
                  Console.WriteLine(t);
              };
}

Sometime back I had the priviledge of reviewing an intern project of some live online game. It was a online cricket playing game that is scheduled to match the cricket world cup coming up. The idea was at the time the real match is going on you can play the same match virtually as well.

The game was ASP.NET based. They designed the game as a state machine and after the various stages like a game is over or a level is over (like end of quater-finals) they needed the Databases to be transitioned to the next state. For that they came up with managed executables that were run by the OS scheduler. They had a bunch of seperate executable (6?) for each state transition and all were wired to the scheduler.

I looked at the whole thing for some time (ignoring all the string concatenations waiting for SQL injection) and asked them on how they expect the whole thing to be hosted and also requested them to come back after they found anyone on this planet other than their family to get this running on their server.

Ok so what is this whole post about? If you ever developed a click-once or any other forms of WPF app and wondering what your ISP needs to do to serve these, head on to http://rrelyea.spaces.live.com/blog/cns!167AD7A5AB58D5FE!1661.entry for the answer.

Today is the International mother language day. I'm sure a lot of people will not get to figure this out as Google didn't change its banner :)

I was chatting with a British friend and we were discussing that the relevance of mother language is not so much apparent to most natively English speaking people because of its predominance. However, on this day in 1952 people in Bangladesh laid down their lives while demanding the right to use their own mother language (which incidentally is also my mother language).

Someone posted on an internal DL on how he can share static fields for all instances of the generic class (among all instances of different closed constructed types). The answer is you can't and I quote the C# 2.0 spec on this (so you better believe me)

§20.1.5: A static variable in a generic class declaration is shared amongst all instances of the same closed constructed type (§20.5.2), but is NOT shared amongst instances of different closed constructed types. These rules apply regardless of whether the type of the static variable involves any type parameters or not.

The only way I can think about doing this is to have the generic type derive from a non-generic base class and define the static field in that. The code looks as follows

class B
{
     public static int bCount = 0;
}

class D<T> : B
{
    public static int dCount = 0;

    public D()
    {
        dCount++;
        bCount++;
    }
}

D<int> d1 = new D<int>();
D<string> d2 = new D<string>();

Console.WriteLine("D::bCount = {0}, D::dCount = {1}", 
                   D<string>.bCount, D<string>.dCount);

 

This prints out D::bCount = 2, D::dCount = 1 indicating bCount is indeed shared between D<int> and D<string> and hence got incremented twice.

I never faced any need to do any such thing and I cannot think of any example where I would need this :(

For some test code I needed to write a small utility that kills all processes running that matches a given name. Like KillApp Devenv.

After writing the code as I normally would, I thought I should Linquify it. So here what I cooked up

    static class Program
    {
        static void Main(string[] args)
        {
            if (args.Length < 1 || args[0] == "-?")
            {
                Console.WriteLine("Usage: KillApp ");
                return;
            }

            (from p in Process.GetProcesses()
                    where p.ProcessName.Contains(args[0])
                    select p).ForEach(p => p.Kill());

        }

        public static void ForEach<T>(this IEnumerable<T> list, Action<T> act)
        {        
            foreach (T t in list)
                act(t);
        }

    }

Sheer beauty. The only glitch was that I had to write a ForEach extension method :( .

Since I never liked DB's a lot (that doesn't include our test manager Dinesh Bhat though) I converted the Linq query to extension method style as in

Process.GetProcesses().Where(p=>p.ProcessName.Contains(args[0])).ForEach(p=>p.Kill());

Thats when I started wondering is this Lisp I'm coding in or C#? Then the order of the parenthesis reminded me it is indeed C#. With Linq life is good :) the only thing that can make me

The Indian income tax law allows certain expenditure and investments to be tax-exempt. The law also demands various proofs if you want to claim exemptions for this. This include original medical bills, rent-receipts, investments proofs. The list goes on. As you can guess this results in standing in a long queue and a lot of other hassles.

However, I don't care much about these things. I have s imple solution for this. I use the following Ruby script to get around all of this.

outFile = File.open "c:\IncomeTax", "w"
outFile.print "Lots of tax"
outFile.close

Ruby-Dooby-dooooo

 

The spelling mistake in the title is intentional :)

Why? Just check out the System.Windows.Forms.Keys enumeration in the .NET (WinForm) Fx. This enum enumerates all the keys on your keyboard. However, someone seems to have made spelling mistakes while creating the enum. Instead of HangulMode we have HanguelMode which got corrected later by introducing the right enum name with the same value. There is one more a bit lower in the same page. This time its IMEAceept instead of IMEAccept.

Well these are small things. What I don't like is marking enums like these with [FlagsAttribute]. I have blogged about this before and its highly confusing as it indicates that these can be used as flags and OR'ed AND'ed. Sometime back someone had written code to pass around the keys the user had pressed at the same time. When user had Ctrl+Shift pressed he kept getting Ctrl only and the shift was dropped. The reason is simple the value of ControlKey is 17 and that of ShiftKey is 16 so the following expression is true

Keys.ControlKey == (Keys.ShiftKey | Keys.ControlKey);

This was fixed later with the System.Windows.Input.ModifierKey enum which is a true flags enum and can be OR'ed without issue. The only problem is that if you are effected in your WinForm code you need to take a reference to ModifierKey which is a WPF (.NET 3.0) assembly.

The Vista busy cursor  is very interesting. Everyone I know liked it instantly. However, it deviates substantially from the hour-glass busy cursors we were used to.

The funny part is that everyone seems to call it by their own name. I sent an email to an internal alias to find out what is was called and got a the correct answer as Activity Spinner or Busy Cursor (hey it was from it's designer so it has to be correct :) ). But other people pitched in with there own names....

1. Shiny CD
2. Wormhole of death
3. donut / Vista donut
4. Energy circle
5. The Pulse
6. Whirlpool