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.

A camera of the future

In the future, when you take a picture of something, the camera generates a 3D scene of it and stores it in memory.

Camera will need 2 lens to work out the distances and generate the 3D model.

Camera will record and generate the textures that we can see.

When looking at the scene from the angle that the picture was taken at, the resolution is as good as a flat-picture camera.

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.