I received a box through the internal mail today containing ten copies of Charles Petzold's new WPF book: Applications = Code + Markup. I've barely had time to do more than riffle through the pages, but I'm looking forward to spending time with it. He takes a novel approach in the structure of his book: he doesn't introduce XAML until the second half of the book, preferring instead to give the first half over to a detailed treatment of the platform as a .NET class library. I obviously can't comment on how well this works yet - I'm reminded of the disappointment I felt when reading the original Microsoft Press ADO.NET book on discovering that strongly-typed datasets were left until the very end of the book - but in Charles' capable hands I'm sure it turns out happily ever after.

Over the years, I've enjoyed many of Charles' works. In common with many other developers, my earliest memories of Windows development were with Microsoft C 6.0 + SDK, for which Programming Windows 3.0 was as essential to successful work as the compiler itself. To see the breadth of his oeuvre, Code goes beyond the traditional realm of developer-orientated books, taking the reader on an engaging journey that gradually builds layers of abstraction all the way from Morse code through basic electronics circuits and finally to a complete operating system.

In short, if you're at all serious about WPF development, buy this book. Charles, thank you for writing it and for your many contributions to the Windows development community.

Sometimes the simplest demos can be the best.

Catherine Heller is our team expert on the myriad of new Windows Vista unmanaged APIs, but she also knows how to get people excited about WPF with less than 100 bytes of code. This is what she typed into a blank file:

<InkCanvas Background="Yellow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" />

Click here to see the results if you've got a Beta 2 or more recent build of WPF. This shows off loose XAML running locally in the browser, along with demonstrating how easy it is to add ink support to your WPF application.

Another one line demo I like to do is this (alright, I confess, I've wrapped it onto multiple lines to make it easier to show on this blog):

<RichTextBox FontFamily="Palatino Linotype" FontSize="72"
             SpellCheck.IsEnabled="True" Typography.NumeralStyle="OldStyle"
             Typography.HistoricalLigatures="True" Typography.DiscretionaryLigatures="True"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" />

Click here to see the results, and try typing a sentence like this: "The affliction started in 1776 and spread. Quickly!" You'll notice cool effects like the swash on the Qu, ct, st and sp pairs, as well as the book-style numerals. If you're particularly eagle-eyed, you might catch the subtle Th ligature that prevents the rightmost descender from the T clashing with the serif of the h, as well as the ffl ligature. If you misspell a word, you'll see the red wiggly line underneath it - evidence that you get spell checking for "free" with WPF.

What's the most impressive WPF demo you can construct in a single line of XAML? Can you improve on these?

I'm often asked for examples of how Microsoft are using WPF in our own applications. We're building up quite a nice little list of teams who are taking advantage of the technology, but inevitably (and unfortunately) most of them aren't ready for public disclosure at this stage. I'm sure most readers of this blog have seen Expression Interactive Designer and Codename "Max", two early examples; you can expect to see other examples disclosed over the coming months.

Of course, WPF isn't the right technology for every project at every stage of development - and that applies internally within Microsoft as well as externally. To throw away the existing Office user interface and replace with one built on WPF would be a considerable engineering challenge that would draw resources away from other, customer-requested features. There may come a time when such an effort is worthwhile, of course, but as with any other project, the return has to be sufficient to pay off the investment.

However, newer applications and utilities have no migration tax to pay, and so we're seeing some fun things starting to emerge. One example from the Office team is the Calendar Printing Assistant for Outlook 2007, which allows you to use a variety of print quality templates to better visualize your schedule or team diary. You can download this application today from the above link; if you've got Outlook 2007 Beta 2 and WinFX Runtime Components Beta 2, you'll be able to use it to print out calendars that vary from the kind of basic views that you'd get out of Outlook itself to much richer year planner views that you could print on a large-format printer and hang on the wall.

I like this application - sometimes we get so wrapped up in slick software like The North Face and iBloks that it's easy to be lulled into thinking that WPF is simply focused on consumer scenarios. But so many of the key concepts of WPF match the challenges that business developers have: complex form layouts, rich data visualization, powerful data binding, inductive UI, and so on. One demo I like to show is an internal dogfood app called AvalonNotepad, which mimics the regular Windows Notepad on pretty much a pixel-by-pixel basis, just to show that you can build regular applications with WPF. Maybe I should start using the Calendar Printing Assistant instead...

We're in the home stretch after five long years of development. As we close in on the RC1 release of WPF, I figured I should put together a few quick notes on where we stand as of today.

One of the counter-intuitive things about large-scale software development is that the goal at this stage of a development process is not to fix every bug, but rather to bring the product to a known level of quality. There's a big difference between these two things. Every time you fix a bug, you obviously introduce one or more changes to how the platform operates. Even if those changes fix the bug, they may well also have some other unintended side-effects, even with the most careful layering and architectural design. As a result, products tend to go through a stabilization phase where the number of bugfixes made goes down, and the "bug bar" (the severity of a defect required for a bugfix to be accepted) goes up.

Over the last few months, the WPF team has been gradually raising the bug bar until we're now pretty much at the stage where the only bugs that we'd accept fixes for are those that would cause a system crash, a loss of data, or some legal or geopolitical issue. In turn, the active bug count has been dropping slowly but steadily - minor bugs that don't meet the above criteria are still investigated, but are likely postponed for the first maintenance release.

Incidentally, we're not purely marching to the beat of our own drum in making the decision of when the product is ready to ship. One of the launch criteria is partner sign-off, and right now we're preparing to start to distribute internal release candidate bits to a small handful of partners who've been working on real applications based on this technology for a number of months or even years. We'll probably distribute a few builds to them, and ask them the question "are there any issues left in the product that would prevent you from being able to ship your own application". We did a similar process for Visual Studio 2005, and it helped us verify that we were at the level of quality that we thought.

A positive sign of how the churn has dropped is that as we prepare to ship the RC1 release, I'm not aware of a single API breaking change between the July CTP release and RC1 (lots of stability, fit'n'finish and performance fixes though - the last couple of months have made a lot of difference, in my opinion). If you've got your application ported to the July CTP bits, you'll never again be forced to make a change to your source code in order for it to run on the RTM bits of WPF, which I'm sure will be a great source of relief for those of you who've experienced the pain of moving code forward from CTP to CTP release until now. Right now, binary compatibility is looking good too - this is all evidence of how things are stabilizing. It's exciting to see - I think we're all hungry to ship the product so that you can all get your hands on a final, production-quality release.

Obviously we're not quite at the same level from a tools perspective - neither the Visual Studio extensions nor Expression Interactive Designer are at a release candidate stage, although they're coming along quickly behind. However, the SDK documentation is looking in great shape - that team deserves a lot of credit for the way they've documented 20,000 APIs while keeping up-to-date with all the breaking changes. Now they've got a couple of months to work furiously on some more conceptual material that will help people to grok the platform and beat that infamous learning curve.

In short, there's never been a better time to start to learn WPF, and RC1 will be a great time to start pushing ahead with anything that you've been saving until more stable bits are ready. There are several hundred customers and partners that are already mid-development with some great WPF applications, and I'm really excited to see what happens as WPF starts to truly hit the mainstream for .NET developers.

In an attempt to add some light-hearted humour to our series of interviews with the WPF team on Channel 9, I got together with Kevin Moore and Robby Ingebretsen to discuss some of the styles and theming work they've been responsible for. This video was really fun to record, and if you've got fifteen minutes to spare, I think you'll get a kick out of it, particularly when you see the new common control we've added to Windows :-)

Check it out here: http://channel9.msdn.com/showpost.aspx?postid=222817

Also check out these other recent interviews we've done on XBAP and XAML, and three cool demos: Scripps, Accruent and Shaxam.