What do you need to get through the Great Depression 2.0? Why, a giant computing table, of course! Sadly, the Surface SDK isn't available to folks without a real Surface (which, I say, is a bummer) so I can only tell you that developing for it is awesome. Lame, yes, I know.

I can't get you the SDK (yet?) or a Surface (I'm broke) but I can tell you what developing for it was like.

Of course, if you DO have an extra US$15,000 lying around, why not let your baby sit on it? That's my thinking.

One of the things I talked about at my PDC BabySmash talk (WMV) was porting BabySmash to the Surface. BabySmash is a simple WPF application that responds to keyboard and mouse input. Since there's no keyboard or mouse in the standard Surface configuration, I wanted to see how had it would be to port it.

I had to deal with these changes in thinking:

Orientation matters. People might be sitting on opposite sides of the Surface

No mouse or keyboard. Many people can touch it at once.

Multifinger resizing. Folks expect to be able to multitouch a Surface and resize items, throw them around, etc.

Different application launcher model. The Surface needs an XML manifest and special icons for its launcher.

Other than these changes, a Surface app is still .NET WPF app, so I wasn't too worried.

Surface Simulator

The first step was to install the Surface Simulator. It only works on 32-bit Vista, so I had to go make myself a 32-bit machine (I'm all 64-bitted up. FTW!) which was a tiny hassle. (Although there ARE some Vista 64 Surface Simulator hacks) The Simulator is exactly what it sounds like. It's not "emulating" however, as a Surface is still a Vista machine underneath. It's more of a frame and some mouse input management to handle multiple mice and make them look like multiple fingers. This works surprisingly well. In the PDC talk, about halfway in, I plugged in three mice, plus the built in touchpad and had multiple virtual "fingers" moving items around the screen.

You create your Surface app as you would a WPF app from File | New Project, hit START and it fires up the Simulator and frames up the WPF app.

Now in my case, I already had an existing WPF application, so I needed to change the type my main Window derived from from "Window" to "SurfaceWindow" and I added an assembly reference and a few namespaces:

BabySmash uses an MVC model, so I'm taking the input from the View and immediately delegating to a main controller object that handles everything.

Orientation

Your app can let the system decide which side of the Surface table the user is sitting on when it starts up. This isn't a huge deal with BabySmash, since it's just shapes, but still there's some text on the screen so I wanted the app to be right-side-up when appropriate.

There are a bunch of new properties on a SurfaceWindow, and one is:

AutoOrientsOnStartup="True"

This changed the orientation of my entire application, basically turning it upside down when need-be. This did mean that I couldn't use any low-level X and Y APIs, otherwise the coords would be "lost in translation." As long as I stuck with high-level stuff like "GetPosition" to pull my X and Y's out, the Surface SDK would handle translation and everything just worked.

Application Launcher Manifest

I needed to create a few icons for my app to live in the Surface Launcher and a manifest. There's other options I didn't use, as well as ways to create animated icons, or to have your application run as an "attract mode" app, to get folks wandering by to stop and touch the Surface.

ScatterView is a custom ItemsControl in our SDK which apps can databind or populate with any type of content. Simply sticking some Image elements in it gives you a basic Photos-like app without writing any code. By baking common manipulations into WPF SDK controls like this, we’re able to free developers up to focus on things that are unique to their apps while designers use Blend to add some custom pizazz.

I changed my AddFigure method to put the new shapes in a ScatterView. I also hooked up a "ContactLeave" event to the new item so that the application would giggle when you lift your finger.

The second issue was that while my BabySmash shapes were draggable and scattered nicely, they weren't resizable. Well, they WERE, except when you resized them, you were resizing the container - that is, resizing the now-invisible Polaroid border. I needed a box to put the shapes in that would effectively lie to the inner control and scale/size them as the outside scaled and resized. Enter the ViewBox, including with WPF.

I put the Control in the ViewBox, and put the ViewBox+Control in a ScatterViewItem. Bam, resizable, scattered BabySmash shapes.

I also got dragging and inertia (physics) for free so you, ahem, the baby, can spin and throw shapes around as well.

This development was all done on the simulator. I never saw a real Surface until I got to PDC last year. The app ran exactly as should. I was a little worried that the real Surface was somehow different, but not so. That was a huge relief.

If you have a very visual, shape oriented application that could benefit from touch and a big screen, porting it to the Surface isn't rocket science.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

The chart was updating as folks were smashing and we even had a Baby vs. Baby fight break out where the "A" people and the "J" people were going at it. Jeff Atwood started the bloodbath with this tweet as he urged on the overflow room along with Phil Haack. That man's trouble, I tell you.

In the talk, I started out with a old .NET 1.1 chart from 2003 and showed it working, unchanged, in ASP.NET 3.5 SP1. It's just a nice reminder that things usually work just as they should. Then I upgraded it to a new .NET 4.0 ASP.NET Chart that I'll blog about in detail soon. Then, I showed the final site with the new Silverlight Charts. Tim Heuer has a great post on how to databind with these new charts.

You can check out the Toolkit Chart samples and run them yourself here. It's nice that the chart sampler actually includes the source code within the Silverlight sample app. You can browse dozens of charts, then switch tabs and see the XAML and code-behind. This all lives in Microsoft.Windows.Controls.DataVisualization, the namespace (so far) for these controls.

My reporting page included a Silverlight Chart and a Virtual Earth control to show where people were smashing from. The data is coming from the Astoria ADO.NET Data Service, which is easy to get to via either JavaScript or from Silverlight.

You add the charts to your Silverlight application by adding a reference to the assembly then assigning a namespace to them:

There was so much announced at PDC, I wanted to make sure that folks heard about this important release that might have been lost in the shuffle. Even better, the source is open so if you don't like it, change it.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

As I've mentioned before, I've got a talk at PDC this year, it's "TL49" and it's called "Microsoft .NET Framework: Overview and Applications for Babies." It's on Monday at 5:15pm in Room 411.

The baby aspect is really secondary, mostly because BabySmash (and what I do with it in the talk) is Not Northwind. This was the strangest Microsoft talk I could sneak past the bosses without them noticing. It also crosses over into other talks and many other products that I'll mention as the week goes on.

Stressful times...I'm nervous because:

I've never tried to do some many complex and intertwining demos at once.

I've never had so many people help out to make it all happen.

It may suck.

I've got like 7 hours of content to fit in 75 minutes.

I've forgotten completely what I'm talking about. ;)

I hope enough people show up. Starting to get the pre-show jitters!

Here's a teaser of what we were able to accomplish at Tim Huckaby's Party tonight in San Diego. More soon!

(That's Clemens Vaster's daughter and yes that's what you think it is. Tim has one at his house. Crazy.)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

One of the things that I noticed immediately when I made the SmallestDotNet was that Firefox was reporting the version of the .NET Framework installed. There's a Firefox extension that is installed with .NET 3.5SP1. I was stoked about this because I'd like users of BabySmash to be able to use ClickOnce from Firefox to launch it.

ClickOnce and Firefox

When you install .NET Framework 3.5SP1, there's a key written to the registry whether Firefox is installed or not. If Firefox is installed later, it will notice the key and use the plugin. If it's already installed, it'll just work. The registry key points to a Firefox Extension (XPI) that acts like the 3rd party FFClickOnce extension that a lot of us installed before.

The registry key is at HKLM:\Software\Mozilla\Firefox\Extensions This Firefox Addin helps ClickOnce applications work from inside of Firefox 2 or Firefox 3. It'll be installed with any installation of .NET 3.5 SP1, including the smaller Client Profile.

By default, as you can see in the dialog, the browser will report just the most recent version of the .NET Framework unless you say otherwise.

What happens if the FFClickOnce extension is already installed?

In Firefox 3 the FFClickOnce add on will automatically get disabled as it has not been updated.

In Firefox 2 the FFClickOnce extension does not alter the user agent string due to a safeguard against creating a user agent greater than 128 characters. What happens when the user clicks on a .application link is dependent on the user’s configuration.

For Firefox 2.0 this is the table of possible prompting/launching configurations. The default for each add-on is marked in bold.

.NET Assistant

FFClickOnce

Result

No Prompt

Prompt

FFClickOnce prompts and handles the click

No Prompt

No Prompt

FFClickOnce handles the click

Prompt

Prompt

.NET Assistant prompts and handles the click

Prompt

No Prompt

FFClickOnce handles the click

When both add-ons are in the default configuration the user will get the FFClickOnce prompt and click once activation will follow the FFClickOnce path which may bypass IE download policy. In all cases the normal ClickOnce UI will be shown.

What this all means is that ClickOnce will work in FireFox 2 and 3, whether FFClickOnce is installed or not.

How's it done?

The plugin is written with standard XUL (pronounced zoo-el) via XML and JS.

As an aside, I think it's cool that the XML namespace for XUL is:http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul

It's a .jar file, and you can copy it out and rename it .zip and open it up. The basic gist is that the plugin watches for a particular MIMEType and application, and if it matches, it launches the ClickOnce application using the the .NET Framework's PresentationHost.exe.

isClickOnce: function(){ var mimeInfo = dialog.mLauncher.MIMEInfo;

// Checking the file extension may be second guessing the webserver // but when 'prompt' is set the user will still have a save button. if (mimeInfo.MIMEType == "application/x-ms-application" || mimeInfo.primaryExtension == "application") { return true; }

It's not too complex, and it's sure nice that BabySmash users can use ClickOnce to launch the smash.

XBAP

XBAPs, or XAML Browser Applications are also enabled in Firefox in .NET 3.5 using the standard NPAPI browser plugin API. The NPWPF.dll enables XBAPs under Firefox.

XBAPs are WPF applications that run inside the Browser's Chrome. They're good for Intranet applications where you want really easy deployment, the complete .NET Framework (as opposed to Silverlight) and a browser's navigational model.

If you type in about:plugins in Firefox, you can get a list, including this one:

Notice the MIME Types that this plugin has registered for and the extensions (suffixes) it handles. Each of these plugins are automatically installed and enabled when you install the .NET Framework 3.5SP1, so you can count on them.

Thanks to Eric Harding, Troy Martez and Jennifer Lee for helping me pull this information together. They're going to be adding more content to the Windows Client website very soon with more details how for developers to package and use the .NET Client Profile. They'll also be releasing lots of documentation and details on ClickOnce and deployment improvements in the framework. I'll point you to everything I can dig up, Dear Reader, as soon as I can.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

BACKGROUND: This is one of a series of posts on learning WPF. I wrote an application for my 2 year old using WPF, but as I'm a Win32-minded programmer, my working app is full of Win32-isms. It's not a good example of a WPF application even though it uses the technology. I'm calling on community (that's you, Dear Reader) to blog about your solutions to different (horrible) selections of my code. You can get the code http://www.codeplex.com/babysmash. Post your solutions on your blog, in the comments, or in the Feedback and we'll all learn WPF together. Pick a single line, a section, or subsystem or the whole app!

One of the pieces of feedback on BabySmash! was that even though people like that the application automatically updates (via ClickOnce) when they sit down to play BabySmash! their babies want to play it NOW. They didn't like that it tries to update itself when you launch it.

When you setup a ClickOnce application, you get a few choices. You can have the application check for updates before it starts and applying updates before it starts, or you can have it check after it starts and install the updates the next time it starts up. Or, you can say Don't Check For Updates.

I personally find this dialog a little confusing. What this really means is "I'll check manually in code."

At this point, I'm still deploying my app as a ClickOnce app, but now the actual updating is up to me. I used to pop up the Options dialog every time the app started, but again, folks complained, so I had to figure out a way to let them know that an update is available without "stopping the action."

When the app starts up now, it fires of a call to CheckForUpdateAsync from inside System.Deployment.Application and listens for a response. This happens in the background (hence "async"):

Except the glow "pulses" between three colors and repeats forever. I set the DesiredFrameRate to a low number like 10 fps rather than what WPF will attempt, which is 60 fps! I'll post later how we can detect how awesome the user's hardware is and scale or turn off animations and effects.

I want to show an update button when the user visits the Options Dialog, which brings me to my awesome volunteer designer Felix Corke (blog). If you want a great WPF or XAML designer, give Felix money. Here's my original Option Dialog:

And here's the Felix version:

Seriously. It hurts. Brings a tear to my eye.

When the user needs to update, I'll do two things. First, there will be a button that says UPDATE!

Second, after they've hit Update there will be a Progress Bar and that will update as the new version is download in the background.

The API is surprisingly easy to use. We check to see if we were launched from the Network, then I check again (really not needed since I did it earlier, but I like to double-check) for an update. This isn't asynchronous, but it's fast.

I setup two event handlers to listen to the UpdateProgress changing, and to get notification when the system has completed the download of the update. Then I fire off an asynchronous update.

The Completed event is also fairly tidy (this one is simplified, and you could always use extra error handling. Note that since this was an asynchronous call, any exceptions that might have occurred elsewhere will show up here in the Error property of the AsyncCompletedEventArgs parameter.

All in all, not much code for me to switch from an automatic ClickOnce Deployment that I had no control over to one I now have not only complete control over, but also one that fits in more nicely with our always improving UI. Also, an FYI, ClickOnce works with WinForms or WPF equally.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.