Quick tip: Initialising Dictionary inline

var dictionary = new Dictionary<string, string>
{
{ "key1", "value1" },
{ "key2", "value2" },
{ "key3", "value3" },
};

var list = new List<string>
{
"value1",
"value2",
"value3",
};

You might notice that I like to leave the comma behind the last element in my inline initializers - this is actually unnecessary.  But having it there means that I can copy/paste entire lines and move them around without worrying about missing comma right at the end.

For example, this is valid code:

var list = new List<string>
{
"value1",
"value2",
"value3"
};

But if I had to swap the order of the elements and end up with this code, this is not valid.

var list = new List<string>
{
"value1",
"value3"
"value2",
};

Generic EventArgs implementation (but isn't really all that useful)

public class EventArgs<T> : EventArgs
{
private T t;
public EventArgs(T t)
{
this.t = t;
}

public T Value
{
get { return t; }
set { t = value; }
}
}

To use this class:

public EventHandler<EventArgs<String>> Notification;

protected void OnNotification(string message)
{
var handler = Notification;
if (handler != null)
{
handler(this, new EventArgs<String>(message));
}
}

While this code is all nice and dandy, I wonder if it's all that useful.  One of the things with custom event args is that they may grow over time, and this implementation doesn't support future scenarios that well.

My colleague Dinesh mentioned that perhaps I'll end up going down the Func<> route, ie:

EventArgs<T>, EventArgs<T, U>, EventArgs<T, U, V>

Personally I think that's a bit challenging:

If I had to add an future int property to my EventArgs<String>, changing the event to EventArgs<String, int> doesn't automatically fix the issue - as all my event hooks will now stop compiling, because EventArgs<String, int> doesn't imply it inherits from EventArgs<String>

Anyway, nice looking bit of code but I'd say not greatly useful.

Missing entry: setting DateTimeFormat.ShortDatePattern across the entire ASP.NET application

This entry is about a week overdue, nonetheless I shall post it now:

In the global.asax, before page execute, do this:

protected override void PrePageExecute(Page page)
{
// change short date pattern of the current culture short date pattern
CultureInfo info = (CultureInfo)CultureInfo.CurrentCulture.Clone();
info.DateTimeFormat.ShortDatePattern = "dd MMM yyyy";
System.Threading.Thread.CurrentThread.CurrentCulture = info;
base.PrePageExecute(page);
}

I'm using CompositeWeb.WebClientApplication here, if you are using vanilla ASP.NET, you can use a whole lot of different events such as BeginRequest.

Take the current culture, clone it (because the current culture is read-only).  Then set the short date pattern to something universal like "dd MMM yyyy";

This affects all instances where these are used:

datetime.ToString("d");
datetime.ToShortDateString();
datetime.ToShortDateTimeString();  // which is a concatenation of "d" and "t"
datetime.ToString();

This fixes issues for our application that is used by both American (MM/dd/yyyy) and Australian (dd/MM/yyyy) audiences.

Ideally, the user would set the language setting in their browser to the appropriate locale (en-US or en-AU), but this is too hard to force upon our non-technical users and the risk of someone misreading a date is too high, so we've opted for the "dd MMM yyyy" format which everybody understands.

jliu

Updating from SilverLight 2 Beta 1 to Beta 2

Cannot specify both Name and x:Name attributes

I think this is a bug in Beta 2, where you can't set x:Name for a UserControl, and then in the parent XAML that uses the UserControl, use x:Name again.

The trick is to remove the name from the XAML for the UserControl - you can use this in the code behind anyway to self reference the user control, so the name here isn't that important.

Update project references

Old SilverLight 2 Beta 1 projects still had references to version 2.0.3xx, some manual add/remove references was required to get the project all happily working on v2.0.50727

That was all the changes I had to do.  I think I escaped lightly this time.  Oh the joy of playing with beta software.

Do we really need that many controls in Silverlight?

I was digesting Scott Gutherie's blog on Silverlight 2 Beta 2

We ultimately expect to ship over a 100 controls for Silverlight.

It really made me wonder, do we really need that many different types of controls built-in with the default Silverlight installation?

Beta 2 now has around about 30+ controls, and the only one that I've noticed is missing, is the combo-drop down list control.

I'm guessing if they really plan to end up with so many controls, then perhaps they'll start by porting across all the various controls that currently WPF have and Silverlight doesn't.

Edit:

Oh and some sort of Menu control