This article also appears in Canadian Developer Connection.

If you’re going to be in the area of downtown Toronto next Thursday, May 28th, you might want to check out my presentation, Canada’s Next Top Model View Controller at the next Metro Toronto .NET User Group meeting. I’ll be talking about the ASP.NET MVC Framework, Microsoft’s answer to MVC frameworks like Ruby on Rails, Django, CakePHP and Catalyst. As is my stock in trade with presentations, this will be informative, enlightening, entertaining and just might feature a rock and roll accordion performance.

The presentation takes place Thursday, May 28th at 6:00 p.m. at the Manulife Financial Building (200 Bloor Street East, Toronto, between Church and Jarvis – use the entrance on St. Paul Square). Admission for the presentation is free, but you have to register, and as of this writing, only 24 tickets remain.

For more details about the presentation, visit the Metro Toronto .NET user group site.

I’ll be in Calgary from Monday to Friday next week, catching up with my friend and co-worker John Bristowe (he’s Microsoft’s Developer Evangelist for Western Canada) and speaking at the Tech Days conference.

If you use (or are thinking of using) The Empire’s technologies, Tech Days is a pretty good place to get immersed. It’s a conference focused on learning about Microsoft tech on its target platforms – PC, web and phone – both current and upcoming. It’s also a chance for Microsoft developers to get together and network, and you leave the conference with a nice package of free stuff, including a full version of Visual Studio 2008 Professional Edition. (And just between you and me, if your company’s paying for it, Tech Days is also a good excuse to get a couple of paid days out of the office.)

In addition to the conference notes and reportage that you’ve come to expect from Global Nerdy and the accordion playing you’ve come to expect from me, I will be contributing in another way: I’m delivering the A Deep Dive into the ASP.NET Ajax Extensions presentation (it’s part of the web development track and taking place on Wednesday, December 10th at 1:00 p.m.. Here’s the abstract for the presentation:

The ASP.NET AJAX Extensions are the server half of ASP.NET AJAX. Aside from adding controls such as ScriptManager and UpdatePanel to the platform, they extend the ASMX model to support client-side callbacks and JSON serialization. In this session, we’ll explore ASP.NET AJAX on the server – both inside and out – in order to provide you with the knowledge you will need to exploit it to its fullest.

(If I had more time, I think I’d write my own abstract.)

I looked at the time slot I was given and went “uh-oh”. It’s one p.m., right after lunch, which is what people used to call the sexta hora in Latin. That means “sixth hour” and refers to the sixth hour of being awake, which is when people start to get a little bit sleepy. That’s where the word siesta comes from – it’s a bastardization of sexta hora. I’m going to have to make sure that I keep things interesting – I welcome that challenge.

See you in Calgary!

While following the exercises in the book Teach Yourself ASP.NET Ajax in 24 Hours – one of the few books I’ve been able to find on Ajax for ASP.NET 3.5 – I found an error in the “Hour 9” chapter in the example that covers client-side error-handling (it starts on page 137). I’ve reported this error to the publisher and with any luck, they’ll post a corrected version on their support web page for the book.

I’ve done some searching and haven’t found anything covering this error so I thought I’d cover it here. Better still, I’ll also cover the fix, which turns out to be quite simple. If you’ve been trying out the code in the book and wondering why it doesn’t work, relax: at least in this case, it’s not your fault.

In the course of covering the error and how to fix it, I’ll also talk about how ASP.NET handles exceptions raised by asynchronous postbacks and how you can make use of it to make better user interfaces. Even if you don’t have a copy of Teach Yourself ASP.NET Ajax in 24 Hours, you should find this article an interesting introduction to client-side error handling in ASP.NET Ajax.

Unhandled Exceptions and Asynchronous Postbacks

In ASP.NET Ajax, if an exception is raised during an asynchronous postback and isn’t handled on the server side – that is, in the code-behind – it gets passed along to the client side. What happens on the client side depends on which version of ASP.NET you’re using:

• In ASP.NET Ajax 1.0, the server-side exception object is serialized into JSON. The JSON is sent to the client, which displays the exception’s message property in an alert box.
• In ASP.NET Ajax for .NET 3.5, the server-side exception is still serialized into JSON and the JSON is still sent to the client. However, instead of displaying the exception’s message property in an alert box – a presumptuous design decision, if you want my opinion – the client throws the exception, which gives you the opportunity to handle it on the client side as you please.

(In this article, I’ll stick to covering ASP.NET Ajax for .NET 3.5.)

This is quite different from most other web application frameworks, where an exception raised as the result of an XMLHttpRequest call to the server results in some kind of “error” page from the server (or a blank page, if you’re suppressing error reporting).

To illustrate this, let’s put together a simple ASP.NET Ajax application. It’s a single page with a single button, that if clicked, throws an exception.

Here’s the code for the page layout. It’s pretty straightforward:

Listing 1: Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

Some notes about the code:

• The ScriptManager control at the top of the form enables Ajax by ensuring that the JavaScript needed to support ASP.NET Ajax on the client side is downloaded to the browser.
• The UpdatePanel control determines the controls that trigger asynchronous postbacks and defines the region of the page that can be updated via Ajax.
• Button1 is the button control that we want to throw an exception when clicked. We’ll set it to call the Button1_OnClick method, which will contain the exception-throwing code.

The code-behind is very simple. In it, we define a single method: the event handler Button1_OnClick, which is called in response when the user clicks Button1. All we want it to do is throw an exception that uniquely identifies itself:

Listing 2: Default.aspx.cs – Code-behind for the page of our very simple example app.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication1
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Button1_OnClick(object sender, EventArgs e)
        {
            throw new Exception("Click!");
        }
    }
}

Running with Debugging vs. Running Without Debugging

Listing 1 and 2 give us enough to make our simple app work. It’s time to take it for a spin.

Here’s something that doesn’t get covered in Teach Yourself ASP.NET Ajax in 24 Hours: what happens when you try to run this app with debugging (starting it by hitting F5 in Visual Studio or “Start Debugging” under the “Debug” menu)?

Here’s a screenshot of what happened for me:

With debugging on, the unhandled exception thrown in Button1_OnClick is caught by the debugger. Normally, this sort of error-catching behaviour is welcome, but in this particular case, it gets in the way of what we’re trying to achieve: having an exception on the server side and passing it along to the user’s browser to handle.

If we run the same app without debugging, we get the effect we want: the exception is raised on the server side, but the server-side part of the application doesn’t halt with an error message. Instead, the client shows the error message.

Here’s a screenshot. Note that the error message includes the string “Click!”, which is the argument in the throw statement the Button1_OnClick event handler. Thanks to this, we can be pretty certain that the error message is the result of our deliberately-thrown exception:

Now that we have the exception that we threw on the server side being handled on the client side, let’s do something with it. 

Handling Exceptions Passed from the Server on the Client Side

Let’s do something simple – let’s catch the exception caused by the button click, and instead of having a JavaScript error box pop up, let’s make a couple of changes to the button:

• Change its text to “This button has been disabled for your safety.”
• Disable it.

To handle exceptions on the client side, we need to write some client-side JavaScript. Luckily, this is made simple by the number of handy utility classes defined in the scripts downloaded to the client by the ScriptManager component. In this case, we’re going to make use of the Sys.Webforms.PageRequestManager class to deal with the exception because it provides us with the following:

• The endRequest event, which is raised after an asynchronous postback has completed and control is returned to the browser.
• The add_endRequest method, which specifies a method to call when the endRequest event is raised.

Here’s the JavaScript, which we’ll put in a file called ErrorHandler.js:

Listing 3: ErrorHandler.js — Client-side error handler for our very simple example app.

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler);

function EndRequestHandler(sender, args)
{
    if (args.get_error() != undefined) {
        $get('Button1').value = "This button has been disabled for your safety.";
        $get('Button1').disabled = true;
        args.set_errorHandled(true);
    }
}

The script performs the following:

• It registers the method EndRequestHandler as the method to call whenever the endRequest event is raised.
• It defined the method EndRequestHandler, which does the following:
  • If an exception did occur during the asynchronous callback:"
    • The button’s text is changed
    • The button is disabled
    • The error is reported as handled, which allows the application to continue

Now that we have this client-side code, we need to get it to the client. We do this by using the Scripts section of the ScriptManager to send this file to the client. The listing below shows the updated layout code for our simple application. I’ve highlighted the change in the listing below:

Listing 4: Revised Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server">
                <Scripts>
                    <asp:ScriptReference Path="~/ErrorHandler.js" />
                </Scripts>
            </asp:ScriptManager>
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

The Scripts section of the ScriptManager lets us specify scripts to be sent to the client along with the page, with each script specified in a ScriptReference tag.

When we run the app (remember, without debugging on) with these changes and click the button, here’s what we get:

In a later article, I’ll look at other ways of using client-side error handling in ASP.NET Ajax in .NET 3.5.

The Error in Teach Yourself ASP.NET Ajax in 24 Hours

Here’s the page layout code for the error-handling example in Teach Yourself ASP.NET Ajax in 24 Hours. The code-behind for the page and the client-side JavaScript are fine, it’s this code that has the error. See if you can spot what’s amiss:

Listing 5: Default.aspx — Page layout of client-side error-handling example in Hour 9 of Teach Yourself ASP.NET Ajax in 24 Hours.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title></title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

        <br /><br />

        <div id="Message" style="visibility: hidden;">
            <asp:HyperLink ID="HyperLink1" runat="server"
                           Font-Bold="true"
                           Text="Error Occurred..."
                           Font-Italic="true"
                           ForeColor="red" >
            </asp:HyperLink>
        </div>

    </form>
</body>

</html>

Just for kicks, here’s what happens when you click on the button in the app using the code straight from Teach Yourself ASP.NET Ajax in 24 Hours:

The mistake is simple: although there is some error-handling client-side JavaScript in the app, it’s not referenced in the ScriptManager tag, which means it’s not sent to the client. Without error-handling code on the client side, the exception is thrown, there’s nothing to catch it and the user is presented with the standard error dialog box.

The fix is equally simple: reference the script in the ScriptManager tag’s Scripts section:

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Scripts>
        <asp:ScriptReference Path="~/ErrorHandlingScript.js" />
    </Scripts>
</asp:ScriptManager>

Once that’s done, the program works as promised.

Interview with Chris Slemp, MSDN

Here’s another video interview featuring Yours Truly at the PDC: it’s with Chris Slemp, Program Manager for the Server and Tools Online group at Microsoft. In the interview, we talk about MSDN and its new social bookmarking feature.

Click here to watch the video.

“Grim Fandango’s” Puzzle Document

If you’re looking to get into the mind of a game designer and the design of one of the most highly-regarded computer adventures games, be sure to check out the Grim Fandango Puzzle Document. Tim Schafer, in “a temporary fit of Cake-induced Grim nostalgia,” decided to put the game’s puzzle design document online in PDF form (it’s 2.3MB in size).

Here’s a great summary of the Grim Fandango Puzzle Document, written by Andy Geers:

I use that word "crafted" because that’s exactly what this newly released document shows: true craftsmanship. We see the incredible attention to detail, the pacing of the narrative as it builds and as the puzzles get increasingly sophisticated, always coaxing the player along with them. As somebody whose spent the last few years trying to write my own adventure game, what struck me most about this document is the sheer simplicity of it – it’s well established that it takes a great deal of clarity and hard work to boil down something so vast as Grim Fandango into such a simple representation that conveys so much information in such a succinct way.

It’s a considerably more interesting read than most specs.

My Job-Related Reading List

Nothing gives you that frozen-caveman-thawed-in-modern-times feeling like returning to a software platform after not developing in it in seven years. Getting back into the swing of Microsoft’s development tools has been fun so far, but it is, as a lot of people have told me, like drinking from the firehose.

To quickly get acclimated with C#, ASP.NET and XNA, I’m expensing the following books I bought today:

• Pro C# 2008 and the .NET 3.5 Platform by Andrew Troelsen
• Professional ASP.NET 3.5 in C# and VB by Bill Evjen, Scott Hanselman and Devin Rader
• Beginning XNA 2.0 Game Programming by Alexandre Santos Lobao, Bruno Pereira Evangelista, and Jose Antonio Leal de Farias

I’ll let you know what I think of these books as I read them.

“Zero Punctuation” Reviews

And finally, a couple of reviews from my all-time favourite game reviewer, Ben “Yahtzee” Croshaw. The first one’s for Saints Row 2, which includes a great argument for why it might actually be a better game than Grand Theft Auto IV as well as a brilliant concept for a new game:

and here’s the latest review, for Dead Space, which he summarizes as “competent but bland”. Luckily, his review is anything but…

A number of people have asked me how many sessions I attended at last week’s Microsoft Professional Developers Conference; my answer was “I only attended the keynotes”. Since every session was recorded on video (with a split screen showing both presenter and presentation) and made available online, I decided to focus on what you can’t replicate outside the conference: getting to know people in the Windows developer community.

It’s standard procedure at Microsoft to assign “buddies” to new hires to help them get acclimated. I have the very good fortune of having John Bristowe as one of my buddies; not only is he a warm and friendly guy, but I also already know him (his sister Ashley and I went to Crazy Go Nuts University together). John’s big on podcasting and was very generous in sharing the interviewer’s chair; he let me do a lot of interviews as a way to both get podcasting practice and introduce myself to people in the Windows world. Thanks, John!

You’re going to need Silverlight to view these videos. If you’re rolling your eyes at the prospect of having to download yet another plugin, keep in mind that Silverlight is a pretty cool tool for writing rich internet apps, I’ll be covering it rather extensively soon, and it’s catching on. Besides, you can’t see the videos without it!

Don Box on My Joining the Dark Side, Demos, Oslo and M, Zombies and How to Pronounce “Azure”

Click the picture to see the video of the interview.

After introducing myself to Distinguished Engineer (yup, that’s really his title) Don Box as “Microsoft’s Newest Employee”, I told him about my coming to Microsoft from the F/OSS world and asked him to please tell me that I hadn’t made a tragic mistake and ruined my life by coming over to the Dark Side. We also talked about his preparation process for his keynote demo, the Oslo platform and the M programming platform, the proper way to pronounce “Azure” and whether or not Microsoft is ready for the zombie apocalypse.

Useful Don Box/Oslo Links

• Video of my interview with Don Box.
• Video of Don Box’s and David Langworthy’s PDC 2008 presentation, Oslo: The Language, which introduces the M programming language.
• Video of Don Box’s and Florian Voss’ PDC 2008 presentation, “Oslo”: Customizing and Extending the Visual Design Experience.
• The Oslo site.
• If you’d like to read more about Oslo in Don’s own words, a good place to start is this entry in his blog.
• Don’s blog, Don Box’s Spoutlet.

Miguel de Icaza on Mono

Click the picture to see the video of the interview.

I had a great chat with Mono Project lead Miguel de Icaza about Mono, their answer to Silverlight, the number of people in the Mono Project and how you, as a Windows developer, can take Mono out for a spin. We also talked about how to pronounce “Azure”, and Miguel speculated that the name was a clever choice because the disagreement over its pronunciation is a great way to get people talking about it.

Useful Miguel de Icaza/Mono Links

• Video of my interview with Miguel de Icaza.
• Video of Miguel de Icaza’s PDC 2008 presentation, Mono and .NET.
• The Mono Project’s site.
• Miguel de Icaza’s blog.

John Lam on IronRuby

Click the picture to see the video of the interview.

It’s always good to catch up with Toronto-area guy turned Redmond guy and IronRuby creator John Lam. We had a quick chat about IronRuby and the current state of the project. In the interview, he reminds us that IronRuby is an open source project, talks about the Ruby standard implementation tests it’s currently passing and what to expect from IronRuby in the near future.

Useful John Lam/IronRuby Links

• Video of my interview with John Lam.
• Video of John Lam’s PDC 2008 presentation, IronRuby: The Right Language for the Right Job.
• The IronRuby site.
• Why’s (Poignant) Guide to Ruby — the most whimsical introduction to a programming language, ever!
• John Lam’s blog, John Lam on Software.

Phil Haack on ASP.NET MVC

Click the picture to see the video of the interview.

Phil Haack not only has the coolest surname for a techie, he’s also got an MVC framework for ASP.NET, just like the ones the Rails, Django and Cake people get to play with. In this interview, we talk about MVC web frameworks for the uninitiated, as well as get his take on how to pronounce “Azure”.

Useful Phil Haack/ASP.NET MVC Links

• Video of my interview with Phil Haack.
• Video of Phil Haack’s PDC 2008 presentation, ASP.NET MVC: A New Framework for Building Web Applications.
• The official ASP.NET MVC site.
• Phil Haack’s blog, You’ve Been HAACKED.

.NET Micro Framework

Click the picture to see the video of the interview.

Believe it or not, there’s a .NET framework for embedded devices, the .NET Micro Framework. In this interview, I learn about .NET programming for small devices, the “Dare to Dream Different” contest (where you can win great prizes for coming up with new applications for the .NET Micro Framework) and about what donuts have to do with microcontrollers. Mmm…donuts!

Useful .NET Micro Framework Links

• Video of my .NET Micro Framework interview.
• The “Dare to Dream Different” contest site.
• The .NET Micro Framework site.