Tales from the Evil Empire

_keyDownHandler = Function.createDelegate(this, this.onKeyDown);

Here, I'm setting the private variable _keyDownHandler (a private variable is a variable declared inside the body of a function/class) to point to the onKeyDown class method. When the delegate is called, it will run within the context of the particular instance that created it and will have access to all its instance properties and methods. Hence, there is no need for global variables. createCallback similarly enables you to create a reference to a function that will remember the arbitrary context object you passed it at creation-time when it is finally called.
If you need to know the result of the call before allowing the user to continue, you shouldn't block the whole browser. What you should do is disable the pieces of UI that should remain untouched while the call is going on (which means other parts of your app can continue to run in the meantime) and re-enable them when the call completes. You can see an example of how to do this declaratively in this blog post:
http://weblogs.asp.net/bleroy/archive/2005/09/20/425698.aspx
Asynchronous calls actually become very natural and transparent in a declarative and event-driven environment such as Atlas is providing.
You may think asynchronous calls are more difficult, but unfortunately until the browsers become multitasking scripting environments (which is not something likely to happen in the foreseeable future imho), they are the only way to create a responsive client web application.

One of the most common mistakes beginner ASP.NET developers make is to call MsgBox.Show from their ASP.NET server-side code. It is a mistake because this code runs server-side and will just display the message box on the server where it's not going to be very useful. Well, in version 2.0, it will actually throw an exception.

In the Photo Album Handler, one of our goals is to have everything in a single file for easy deployment (we still need an additional separate dll in version 2.1 but we're getting there). I also wanted the handler to be able to act like a Control so that it can be integrated in an existing site. Even when used in control mode, the handler part is still necessary to serve the thumbnail and preview versions of the images. We also want to enable the handler just by dropping it into the image directory without having to modify or create a web.config file, which forces us to use a .ashx file.

Last night, I uploaded the source code and release package for version 2.0 of the photo handler. I'll post more about the details of this new version in the next few days, but I can tell you that most of it has been rewritten, and it can now be used as a standalone application or as a control. What's more, the control is fully templatable, so if you don't like the default rendering, you can take it over and create your own. I've included a template example that reproduces the default rendering, which should give a good starting point.

Download the handler from here:
http://www.codeplex.com/PhotoHandler

Well, if you have not pre-ordered six months ago and weren't ready to spend a good part of yesterday and last night freezing in front of Best Buy, your chances of scoring an Xbox 360 were near zero. So if you're like me, you just made fun of the guys waiting during this wet and cold night and just resigned to go home and wait for the next shipments.

Here's a misconception I see a lot on the forums lately. There is this idea that controls on a master page should always keep their state across content pages that use it.
When you navigate away from a page (i.e. when you click a link), you go to another page, with another instance of the controls on it, so of course the new controls on the new page have no way of knowing about the state of the controls on the other page.
Having a master page does *not* mean that all the controls on the master page have a unique instance that would be shared by all pages that use this master page. The master page is nothing more than a template, it's not any kind of singleton.
So the only way you can maintain the state across different pages (whether you use a master or not) is by storing it in Session and using that information when a new page is loaded. This can have severe performance drawbacks as you store state for each user but is more or less what WebParts do with their personalization data...
Another approach is to consider that if you need to maintain state across all those pages, maybe they are the same and you need to move from a many-page model to a single-page model.
Please note that the navigation controls (a.k.a. Menu, TreeView, SiteMapPath) will automatically select the current node in the site map according to the URL you're on, giving a minimum version of this application-level state management some were expecting from master pages.

If you want to check out what a real-world complex Atlas application would look like, Nikhil put together an amazing Atlas app around Virtual Earth and a few other web services such as Flickr and Amazon.

After years of hard work, version 2.0 of the .NET framework was launched this morning. This is a major event and something I think we're all proud of. We also launched Visual Studio 2005 (including Visual Web Developer Express), Sql Server 2005 (check out the free Express version) and BizTalk 2006.