Charles Petzold

A book on the Windows Presentation Foundatation (formerly known as Avalon) is intrinsically more complicated than other Windows programming tutorials. The reason? It has two APIs.

WPF has a relatively normal object-oriented procedural API for coding with C#, VB, etc, but it also has a parallel XML-based API known as XAML, the Extensible Application Markup Language. The basic idea is that you do the program layout (pages, form design, dialog boxes) in XAML and then write event handlers in code.

One of the things I like about Windows Forms is that everything is done in code, including menus and dialog box layout. You can do a short program — or a whole dialog box in a larger program — entirely in one C# file. This seemed to me a massive improvement over the old Windows API approach of splitting the program between code and resource script.

At first I was a little hesitant about embracing a new API that went back to that split between code and script. But the power built into XAML is truly amazing and ultimately converted me. (In the article on Avalon I wrote for MSDN Magazine, I almost wrote that XAML was "a resource script on crystal meth" with the knowledge that the editors would probably change it to "steroids" but I decided that any comparison with the resource script was insulting.) For larger software house and larger applications, it can allow application development to be split effectively between designers and programs.

For Visual Studio users, splitting off layout into a separate file has an extra potential bonus: Maybe Visual Studio can stop generating code that it doesn't let the programmer modify (and would prefer that the programmer not even see). It's certainly safer and more rational for Visual Studio to generate and maintain XML than C# code.

Yet, I believe that XAML makes most sense as an alternative to precedural code rather than a replacement for it. Everything you can do in XAML you can also do in code (although the code is certainly more verbose). It seems obvious that any Avalon programmer needs to know XAML, but just as importantly, needs to know how to write applications without XAML.

For that reason, my book will definitely start with writing programs purely in C#. Eventually, of course, I'll begin introducing XAML, but I'm not sure how soon. The book is supposed to be 900 pages long. How many pages could I go before the first XAML chapter? Two hundred pages, perhaps? Even then, I think, I'd like to start slipping some XAML into the applications a little at a time, and really focus on the equivalent code. There are, of course, several huge topics in Avalon programming — I'm thinking styling and animation — where I really want to stress the use of XAML, but until then I'd like to maintain a balance.

Of course, Visual Studio doesn't help at all. You tell Visual Studio you want an Avalon app and it generates two XAML files, five C# files, a .resx file, and a .settings file. So once again, I'm forced to use the Empty Project approach. Visual Studio may be great for programmers, but it's a disaster for people like me who write programming tutorials.