Charles Petzold

Something in Don Box's analysis of WPF books has been bothering me. Here it is:

As a WPF user, I spend at least as much time reading and writing XAML as I do reading/writing C# code that does WPF-isms. I do spend a lot of time in C#, but little of it is WPF specific, which arguably is one of the strengths of WPF’s data/content facilities.

The second sentence seems to conflict with the first. The first sentence indicates that the C# code Don reads and writes "does WPF-isms" but the second sentence says that little of his C# code is "WPF specific." Maybe I'm just reading it wrong, but...

It is my experience that when you design a class for use in WPF, you're very likely deriving from DependencyObject and quite often something higher up the food chain (depending what you're doing). Deriving from DependencyObject itself is non-trivial: The use of dependency properties implies quite a different class architecture than most programmers are familiar with, both internally and externally.

In fact, "one of the strength's of WPF's data/content facilities" (in Don's words) is the built-in notification mechanism provided by the use of dependency properties, which are very WPF specific.

My book Applications = Code + Markup has a whole chapter on dependency properties, but I think the book could have used much more, In fact, I think a whole C#-only WPF book could be written that shows how to design classes that are amenable for use in WPF applications and XAML. A sample chapter outline:

Who's Your Daddy:
Class Derivation in the Windows Presentation Foundation

1. Finding the Right Base Class for You
2. Deriving from DispatcherObject
3. Deriving from DependencyObject
4. Deriving from Freezable
5. Deriving from Animatable
6. Deriving from AnimationTimeline
7. Deriving from Visual
8. Deriving from ContentElement
9. Deriving from FrameworkContentElement
10. Deriving from Visual
11. Deriving from UIElement
12. Deriving from FrameworkElement
13. Deriving from Panel
14. Deriving from Shape
15. Deriving from Control

I'm sure anybody who's done some WPF coding can think of one or two additional chapters they'd like to see in this hypothetical book.

Don seems to indicate that he spends about equal time with XAML and C# code. In the future I wonder if he or I (or any other WPF programmer) will be spending more time with XAML or less. I think less: For some time now, some developers have been asserting that XAML is for tools rather than hand-coding. As anyone who reads this blog knows, I have found great joy in hand-coding XAML and pushing it to the limits, yet this is not likely to be a marketable skill in the years ahead.

XAML itself is easy compared with designing classes that work well with XAML. In various ways these classes must make themselves amenable to the features of WPF that are most easily accessed in XAML, such as styling, data binding, templates, and animation. This is the real challenge for WPF programmers.