A number of years ago, the two of us worked at the same company and had to design a new form definition language for an entirely definitionally-driven system. The definitions were to be stored in XML. They had to be loosely bound to data definitions, and allow for complex behavior changes based on data. The individual elements of a form had their own properties, but also had to store properties that they didn’t care about but that were relevant to higher-level layout mechanisms. We built this long before WPF was even a glimmer of a concept at Microsoft.

We’d like to pretend that Microsoft saw our brilliant design and decided to copy it when creating WPF, but that would be a lie, and we only lie when we’re fairly sure that our facts can’t be verified elsewhere.

Nonetheless, WPF does encapsulate all the basic design principles that we had for our form definition language, and then goes soaring off to leave our pitiful efforts in the dust. When we first started playing around with (extremely) early versions of what was then called Avalon, we had a lot of “duh, why didn’t we do it that way” moments as well as, to be kind to our battered egos, a few “yeah, that’s how we did it” moments.

We’re both extremely comfortable in the Windows Forms (and the Windows SDK) world, so moving to WPF was both a happy and sad experience—sad in that we watched a lot of our hard-won knowledge become obsolete, but happy in that WPF made us way more productive, and let us do things quickly and easily that we would have just skipped with Windows Forms because they would have taken entirely too much effort.

Not that everything was a bowl of things that you like to keep in bowls—particularly with early betas and lack of documentation; we definitely spent time whining and banging our heads into walls. Overall, though, we are pretty happy with WPF, and are looking forward to where it’s going to go in the future.

Fast forward a year or two, and one of us foolishly answered a phone call from Mike Stephens at Manning, asking about a completely different project. After many abject refusals, the conversation turned to WPF and the fact that there weren’t many/any books out there that covered both WPF and Visual Studio 2008. Some slightly less abject refusals later, we suddenly discovered that we’d signed a contract to produce said book and have it ready in time for the release of Visual Studio 2008.

The astute reader might check when VS 2008 came out and the published date on this book and realize that we didn’t quite make our original deadline. But, rather than laziness on our part, this really speaks to our timing genius—we managed to completely revise the book to take into account the many changes in Visual Studio 2008 SP1, which was released not long before these words were typed.

The goal of this book is to provide a practical guide to building WPF applications using Visual Studio 2008 SP1. It isn’t intended to replace the MSDN reference material, but to provide guidance on how to get started and what you need to know to be productive in WPF. Productive is a relative term, of course—WPF has a lot of cool capabilities that can enhance your apps in many ways—and suck up all your available time with tweaking. It’s up to you whether you can really ship your application without that flaming drop-shadow...