Charles Petzold

This may seem obvious (or maybe not), but to me the most important element of writing a good programming tutorial is getting the order of presentation right. Everything should build on what's already been presented without an excessive amount of skipping around and preferably with no forward references. Whenever I need to write something like "You'll learn about this more in Chapter 17 but for now just take my word for it," I feel like I've failed.

This has been a very good work week with almost five full work days of six to eight hours each. I really feel like I'm getting into the desired state of total immersion. I haven't done much real writing yet, but I've been doing a lot of exploring of basic controls and panels, and I'm now ready to write the first few chapters — if only I knew what they were. Here's the problem:

Windows Presentation Foundation programming begins with an Application object and a Window object. That much is obvious. But from there, it's a little tricky. The Window class derives from ContentControl, which defines a property named Content (of type object) for the content of the window's client area. Now this Content object is very flexible. It can be nearly any object, and for most objects, the window will use the object's ToString method to display it. If, however, the object derives from UIElement (as all controls do, plus lots of other cool things), then the object is displayed graphically through its OnRender method.

The problem is that this Content property of Window can be only one object. It seems natural to start exploring simple controls right after Window has been introduced and explored, but the Window itself won't host more than a single control. It seems kind of silly writing one-control sample programs, but it looks like I'm stuck doing that.

The alternative is tackling panels immediately after Window. If you set the Content property of the Window to one of the panel objects, then the panel can host multiple controls and other panels. Panels and dynamic layout consitute a big important topic, and it must appear early in the book, but if I start with panels before discussing a few controls, I have nothing to put on the panels. The whole subject becomes way to abstract.

I think my solution will be to discuss a few basic controls, then cover the most important panels (which I tally as Canvas, DockPanel, StackPanel, FlowPanel, and Grid), and then continue with the more complex controls.

One technique I like when structuring a book is to identify limitations, and then present ways of overcoming those limitations. (Too much to display in a window? The solution is scroll bars!) It's almost like the conflict, resolution, and catharsis in traditional drama. Being able to put only one control in a window is certainly a problem. But the Button has the same Content property and the same problem. You can put text in a button, or a bitmap, or some vector graphics, but only one object. Listbox items are the same: These can be text, or images, etc, etc, but only one. Panels not only solve the problem with the Window, but also provide the same solution for the Button and ListBox items.

Discussing panels very early in the book is essential. Windows programming books have always needed to tackle layout early on. But until recently, layout was basically analytical geometry and the Cartesian coordinate system. That approach has now been relegated to Canvas, which in context is perhaps the least important type of panel. As far as I'm concerned, dynamic layout is the way to go, and a primary objective in my book is to show my readers skillful ways of using it.