XTab's Blog

  I now have several WPF books. I've written reviews on some of them and often mentioned them in answers to Forum questions from members who want to start out in WPF.

  When I wrote those articles and answers, my opinion was mostly based on my experience as a general reader who was interested in seeing what WPF had to offer and dabbling with it at a fairly elementary level. For the past three months though, I've been involved with WPF on a daily basis in a training capacity. During this time, it's become clear that I turn to some of the books much more regularly than others - and to some of them only when fairly desperate).

  With the very clear understanding up front that this is my personal experience, opinion and preference - which may be completely different from anyone else's - here is my view on the various books.

The book I first turn to is :
Pro WPF with VB 2008: Windows Presentation Foundation with .NET 3.5
by Matthew MacDonald.

  Comprehensive, detailed, clearly written, understandable code snippets, and downloadable code samples that work.

  It's almost impossible to fault this book.

  And of course, as the title says, the code behind samples are all in VB.NET - the only book I know of so far that is aimed specifically at VB developers.

  However, if you are a C# developer then that won't impress you much. For you, Apress and Matthew MacDonald have produced the equivalent C# title - Pro WPF with VB 2008: Windows Presentation Foundation with .NET 3.0. The key differences obviously being the absence of "VB.NET" in the title and the slightly earlier Framework.

  I do have this version too and find it very useful when I want to try and understand the C# approach to a concept that I understand in VB.

  The next book I reach out for is usually
Windows Presentation Foundation Unleashed
by Adam Nathan.

  The key value of this book is that it is packed with little hints, tips, Gotchas and information that will help you fight your way through the minefield that you encounter when first starting with WPF.

  One negative for me is that the code samples are in C#. There are however many useful XAML samples.

  The book is in full color. This makes it slightly more attractive, but isn't a key issue for me.

  Compared to most other WPF books, it appears to be relatively slim. In spite of this, I have still found it to be a gold mine of really useful WPF nuggets.

  Third in line is:
Programming WPF
by Chris Sells and Ian Griffiths.

  Another C# book, but again contains a lot of XAML. Ian Griffiths was one of the first writer/speaker/presenter/trainers on WPF in general and XAML in particular, so there are some useful insights to be had here.

  On the negative side, my impression is that the authors prefer to use code behind sometimes where I would have liked to see the XAML alternative.

  Make sure you get the Second Edition if you decide to go for this book. The First Edition is inevitably way out of date now.

  Surprisingly (to me anyway, considering I spent a lot of time converting the code in the next book from C# to VB) the Petzold book only comes fourth in my list of most used books. This is:
Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation
by Charles Petzold.

  If you want intricate details and almost philosophical insight into the structure of WPF, then this would be the book for you. As with all Petzold books, it painstakingly works its way through the minutiae of the subject.

  If I have a criticism, it would be that sometimes the sackcloth and ashes approach to developing (such as manually creating everything yourself, even if it is available for free) doesn't always work for me. I understand the purity of the approach, but this means that it can sometimes be difficult to just dip into this book for a quick answer to a particular question.

  However, if you really - really - want to get at the nuts and bolts of WPF, then you will probably not find one that has more detail.

  The fifth book in my WPF stable (for now, anyway!) is:
Professional WPF Programming: .NET Development with the Windows Presentation Foundation
by Chris Andrade and others.

  When there were very few other books available, this one had some benefits. The authors had each looked at specific areas and came up with some guidance. Some parts were clearly better than others, but overall it was an easier read than MSDN at the time, but basically rather shallow coverage.

  It rarely gets opened these days.

  I have the greatest respect for anyone who takes the time, trouble and effort to write or co-write a book. Knowing how long it takes me to write a short article or a training package, I wouldn't dream of criticising someone who will have spent many long, hard months writing (and no doubt re-writing) a book. So, as I said at the start, the opinions in this blog item only reflect my personal experience of using this collection of books; other readers with other backgrounds and author style preferences may well have different opinions.

  As WPF picks up speed and interest grows, I'm sure there will be many other WPF books published in the coming months. There are already several that were published at the end of 2008 that I haven't read.   No doubt the temptation to pick up another title or two will become irresistible as 2009 progresses and, if so, I will post up my thoughts on those too in the hope that it might help you decide the best way of spending your hard-earned cash.

  Some weeks ago I wrote a blog item about how to get the functionality of PerformClick in WPF.

  I remember thinking at the time that it was a fairly clunky workaround and wondered why PerformClick hadn't been included in WPF. Of course there may be lots of reasons, beginning with 'No-one thought of it' and ending with 'It was just too difficult'.

  But while looking at an apparently unrelated problem this week, it occurred to me that maybe there is a more elegant solution staring me in the face - WPF's Commands.

  In many cases where PerformClick is required, the situation is that whatever action is wired up to the Button's Click event is often also of interest to other controls - perhaps a menu item, a keyboard shortcut or a user instigated selection of some kind or other elsewhere.

  WPF Commands, if this is a new area for you, is a variation on the theme of Events. Whereas events are generally locked in to a specific action, a Command on the other hand is more along the lines of a loosely-coupled task that can be subscribed to from several places.

  Of course,you may be sat there thinking that it doesn't take a coding genius to create code for events that can be re-used and accessed from several different points. The point is though that Commands are specifically designed for this purpose and they have a feature that I think makes them almost unique. (Can you be 'almost' unique, the literary critic part of my brain asks? Never mind, you know what I mean!)

  Commands have the ability to turn themselves off in situations where it wouldn't be appropriate for them to be available - and back on again when it is. A common example is the Paste Command, where it doesn't make sense to have it available unless there is some data in the Clipboard.

  Similarly, you might build in a test where the Exit command isn't allowed to function unless the user has taken some action, such as saving data. There are lots of similar examples.

  WPF comes with a bundle of pre-built Commands for common tasks, including Copy, Cut, Paste, Find, Save, Close, Play, Zoom, Align and many more. Naturally, the designers of WPF don't know the exact actions you will want to link to each of the commands in every circumstance, so there is still some work for you to do. Commands are clever - but they're not magic!

  Apart from the built in Commands, and on the basis that there are never enough of these kind of things, you can create Commands of your own relatively easily. You can set the bindings and the rules that decide when it may be able to execute and when not (as per the Paste example earlier).

  All of which brings me back to my original thought. If you can create a Command that both a Button and (in the case of the Forum question that got me thinking about this) a Menu Item can bind to, then that really removes the need to worry about PerformClick. Command would be a neater and more sophisticated way of achieving the same effect.

  If you want more info on Commands, here is a useful link to an MSDN Introduction to Commands article.