Why am I reviewing a 3 year old book? It is precisely because this book is 3 years old that I’ve chosen to review it now simply because the book is that good. Of all of the books that I use, this one has helped me more than any, without question. And it still helps me. 

Yesterday, when I was writing my post WPF and the Event Routing Paradigm, with Bacon, I went through my books to make sure that I was not only being accurate, but thorough. I wanted not only the conceptual overview and walkthrough, but plenty of technical meat so I could be certain that what I was writing would be truly useful for the people for whom I’ve written it. More importantly, I didn’t want any gaps or omissions.

Many of the books gave only a cursory explanation of Routed Events, something I find to be mindboggling. WPF isn’t easy and Routed Events aren’t intuitive. That’s why I chose the “racing pigs” metaphor. Makes you want to go look, doesn’t it? Of all of the book, only WPF had the technical depth I was looking for.

But it’s 3 years old!

So? Yes, we’re at WPF 4 and 3 versions of .NET later (3.5, 3.5 SP1, and 4.0), but the information in Programming WPF is simply that good that it doesn’t really matter. Most of what’s changed in WPF recently have been additions and not breaking changes. The books strength isn’t that it’s on the bleeding edge of technology, it’s that it leaves no stone unturned in what it does cover.

Positives

• In depth – It covers its topics with such depth that it is very nearly a reference book on par with MSDN articles on the subject.
• Broad – There are very few areas of WPF that are left untouched, including 3-D, printing, and text processing.
• Accessible – The writing is very clear and understandable. Many writers may know their subject but no matter how many books they write, they still can’t quite explain their subject clearly. Griffiths and Sells don’t suffer with that problem.
• Indispensable – This book is truly useful. It’s one you will pick up again and again until its pages are worn.
• It’s heavy – At 835 pages through the index, think of the exercise you’ll get! It is exercise and it counts. That’s my story and I’m sticking to it.

Negatives

• It’s dated – I have to say it. Some subjects just aren’t covered because they didn’t exist when the book is written. I can’t find that there’s going to be a 3rd edition, which would be a shame.
• Silverlight chapter is useless – Sorry, Shawn. It’s just because it’s dated (see above).

I honestly can’t say enough good things about this book. It has helped me immensely over the past few years and it still is. If you don’t have Programming WPF, you seriously should consider getting it.

	Subscribe to event
	Event fires
	Deal with event
	Breakfast!

All in all, it’s pretty simple.  And life was good.

So along comes WPF and things start to get a little more complicated. Events no longer have a simple one-to-one relationship. The event cycle may not be what you expect.

	Subscribe to event
	Event fires
	Events everywhere!
	Deal with event
	Events still running away!

As I said, it’s not quite what you expect. Previous to WPF, event handling was very direct and closed. An event went where it was told and that was that. With WPF, events have a mind of their own, or so it would seem.  But once you begin to understand what happens and why, WPF’s event-handling paradigm begins to make a lot more sense. And this paradigm is called Routed Events.

Manual versus Automatic

Windows Forms style event-handling is very manual. You subscribe to an event, deal with the event and it’s over, whether you like it or not. On one level, it means there are less pieces to worry about, less things that could go wrong. But the more you work with that style of event-handling, you realize how much your handcuffed by it.

To demonstrate the Windows Forms or CLR approach, I’ve made a Forms application to demonstrate how event processing occurred previously (and still does in non-WPF & non-Silverlight applications)

And the following code-behind:

public partial class Form1 : Form

{

    public Form1()

    {

        InitializeComponent();

        button1.GotFocus += new EventHandler(button1_GotFocus);

        button2.GotFocus += new EventHandler(button2_GotFocus);

        tabControl1.GotFocus += new EventHandler(tabControl1_GotFocus);

    }

    void tabControl1_GotFocus(object sender, EventArgs e)

    {

        textBox1.Text += String.Format("tabControl1 GotFocus{0}", Environment.NewLine);

    }

    void button2_GotFocus(object sender, EventArgs e)

    {

        textBox1.Text += String.Format("Button2 GotFocus{0}", Environment.NewLine);

    }

    void button1_GotFocus(object sender, EventArgs e)

    {

        textBox1.Text += String.Format("Button1 GotFocus{0}",Environment.NewLine);

    }

}

Pretty simple.  When you it, you get:

All I did was tab through the controls and it printed exactly one line each time.

This is because normal events are “one and done” in the sense that once they are dealt with, they are considered to be handled and it’s all over.

Now let’s take a look what happens in WPF.  I made a simple form in WPF (if anything in WPF can be considered simple, but this one actually is) and wired the GotFocus event for each of the controls, but I also wired it up for the form itself.

The XAML:

<Window x:Class="WPFEventDemo.MainWindow"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        Title="MainWindow" Height="350" Width="525" GotFocus="Window_GotFocus">

    <Canvas>

        <TabControl Canvas.Left="80" Canvas.Top="46" Height="100" Name="tabControl1" Width="200" GotFocus="tabControl1_GotFocus">

            <TabItem Header="tabItem1" Name="tabItem1" GotFocus="tabItem1_GotFocus">

                <Grid GotFocus="Grid_GotFocus">

                    <Button Content="Button1" Height="23" HorizontalAlignment="Left" Margin="20,11,0,0" Name="button1" VerticalAlignment="Top" Width="75" GotFocus="button1_GotFocus" />

                    <Button Content="Button2" Height="23" HorizontalAlignment="Left" Margin="20,39,0,0" Name="button2" VerticalAlignment="Top" Width="75" GotFocus="button2_GotFocus" />

                </Grid>

            </TabItem>

            <TabItem Header="tabItem2" Name="tabItem2">

                <Grid />

            </TabItem>

        </TabControl>

        <ScrollViewer Height="116" Canvas.Left="28" Canvas.Top="172">

            <TextBlock  Name="tb" Text="" Width="446" />

        </ScrollViewer>

    </Canvas>

</Window>

And the code-behind:

public partial class MainWindow : Window

{

    public MainWindow()

    {

        InitializeComponent();

    }

    private void button1_GotFocus(object sender, RoutedEventArgs e)

    {

        tb.Text += String.Format("Button1 GotFocus \n");

    }

    private void button2_GotFocus(object sender, RoutedEventArgs e)

    {

        tb.Text += String.Format("Button2 GotFocus \n");

    }

    private void Grid_GotFocus(object sender, RoutedEventArgs e)

    {

        tb.Text += String.Format("Tab 1 Grid GotFocus \n");

    }

    private void tabItem1_GotFocus(object sender, RoutedEventArgs e)

    {

        tb.Text += String.Format("tabItem1 GotFocus \n");

    }

    private void tabControl1_GotFocus(object sender, RoutedEventArgs e)

    {

        tb.Text += String.Format("tabControl1 GotFocus \n");

    }

    private void Window_GotFocus(object sender, RoutedEventArgs e)

    {

        tb.Text += String.Format("----------------------------\n");

    }

}

And when you run it you get:

with the following in the TextBlock:

tabItem1 GotFocus

tabControl1 GotFocus

—————————-

Button1 GotFocus

Tab 1 Grid GotFocus

tabItem1 GotFocus

tabControl1 GotFocus

—————————-

Button2 GotFocus

Tab 1 Grid GotFocus

tabItem1 GotFocus

tabControl1 GotFocus

—————————-

Each section is the result of a single press of the tab key, including the dashed line. What you’re seeing is the result of event bubbling and this happens every time an event is fired in WPF and Silverlight.  Look at the second group. When I tabbed to the button, it fired GotFocus for the deepest, nested object and then bubbled up doing likewise to each object in the tree until there were no more left. In fact, the GotFocus event for MainWindow is what added the dashed line at the end.

But what if you don’t want that behavior?  That’s simple enough. You may have noticed that I haven’t been using the term “handle” for dealing with events. This was intentional, because “handled” has a specific meaning in RoutedEvent processing and now you’re going to learn what.

If you don’t want events to bubble up past a certain point, all you need to do is set Handled=true for RoutedEventArgs in the handler. At that point the bubbling stops and WPF truly considers the event completely handled. What is key is that I said “past a certain point”. You can stop the bubbling anywhere in the hierarchy, not just at the control that caused the event.

In the following code, I’ve set Handled to true at Button1 and tabItem1.  Watch what happens.

Again, I tabbed 3 times. The first tab gave focus to tabItem1 and since I set Handled to true in tabItem1, that’s all it printed. The second tab went to Button1 and since Handled is true in that method, it also just prints one line. But I didn’t set anything in Button2 so when I tabbed to that control, it ran the handlers for Button1, the unnamed grid that is it’s parent and tabItem1, again stopping.

It’s important to note that if I had clicked tabItem2, it would have printed “tabControl1 GotFocus” and a dashed line because I never removed those handlers.

Conditional handling

I put the following code in the the tabControl1 GotFocus handler method:

private void tabControl1_GotFocus(object sender, RoutedEventArgs e)

{

    Control osControl = e.Source as Control;

    if (osControl.Name == "button1" || osControl.Name == "tabItem2")

    {

        e.Handled = true;

    }

}

And what you’ve got is a very simple way of conditionally deciding if you want the event to keep bubbling all the way up the tree.

I hope I’ve given you enough information so that in your own events processing you can turn this…

into this…

(ALTERNATE VERSION for vegetarians)

I hope I’ve given you enough information so that in your own events processing you can turn this…

into this…

[Side note: Yes, I know I only talked about Bubbling and WPF also supports Tunneling.  I’ll cover Tunneling in a future post!]

[Side note 2: Yes, I also know that Routed Events are not a new subject in the WPF and Silverlight world, but I was asked about them and it's never a bad time to go over the fundamentals.]

In the English language, all of the letters of the alphabet have one syllable. Well, except for one. And that letter is the dreaded W.

In the world of computers, we have acronyms for almost everything, and what we doesn’t have a TLA has an abbreviation instead. Unfortunately, since Microsoft chose to name their flagship product Windows, much of those TLA’s start with the dreaded W.

Whether software developers are efficient or just lazy is a topic for debate. As I will note, I tend toward believing in the “lazy” angle.

What is this letter?

W

Say it out loud.

Do you say “double – you”?  Of course you do. You don’t say “dub”. Nobody says “dub”.

So tell me, why in the world would you ever pronounce “WCF” as “dub see eff”?!

Are you that lazy?  Really?  Are the syllables “bull you” really slowing you down so much that you have to just drop them? Is your tongue so tied and twisted that you can’t say them fast enough?  I picture this exchange.

Bob: I learned a tongue twister today.Seven silver swans swam silently seaward.

Jane: That’s nothing. Try “WCF and WF”

Bob: Stop!!! It’s too hard!!!

Ok, I’m done with my rant.  But let’s be real. saying “dub-eff” or “dub see eff” just makes you look stupid.

Friends don’t let friends butcher the language.

What do you do?  Well, you can do what I and a few others did and spend hours uninstalling and reinstalling various software in the (vain) hope that it will solve your problem.  It won’t.

Or you can learn from my experience and solve the problem in a matter of minutes.

Let me ask you first, do you have OpenOffice on your computer or have you ever had it? I can say with a degree of certainty that therein lies your problem.

Apparently, there’s a typeface called “Deja Vu” from Bitstream that Blend 4 RC doesn’t like. And by “doesn’t like” I mean, “makes your program go boom”.

There’s an easy fix.  Delete the font files. That’s all there is to it.  Since Blend is a technical tool, I’m not going to tell you how to delete the files.  If you don’t know how, it’s worth your time to figure it out.

If you want to know how I figured this out and get a little more detail on the error messages, go over to this thread where my answer was originally posted.

And remember, friends don’t let friends use OpenOffice.

Update

Microsoft has fixed the problem and released an update to Expression Blend 4. I haven’t tested it myself (since I removed the offending font) but hopefully this does the trick!

1. Attached Properties
2. Visual & Logical Trees
3. MVVM
4. Prism
5. Click-once deployment
6. Browser apps
7. Animation
8. Graphics (2D)
9. 3D Graphics
10. Flow Documents & Text
11. Ink
12. Printing & XPS
13. Media
14. Adorners
15. Custom controls
16. Interop

And even this is not a complete list.

Remember, WPF is a new paradigm in software UI development. It does have a significant learning curve and it is a huge mistake to oversimplify it.

Grok means to understand so thoroughly that the observer becomes a part of the observed—to merge, blend, intermarry, lose identity in group experience.

or in other words, to fully completely understand and internalize it.  It’s the difference between knowing something because you have read it and truly knowing how it works and why.  I would say that it’s the difference between intellect and application.

As I’ve said before, WPF is in many ways a paradigm shift in software development, especially if you’re coming from the Windows Forms world.  As a result, there are a number of new (and/or different) concepts that you really have to grasp, or grok before you could ever consider yourself proficient.  I’ve been working with WPF for about 2 years now and there are still things that make me stop and think.  Having said that, I think the effort is certainly work making and the result of your hard work is software that is also worth making.

So for budding WPF developers, I give you a list (as opposed to a tutorial) of what I think are some of the most important concepts and methodologies that you really should master in order to get the the most out of WPF.

1. Dependency Properties – It is impossible to be even remotely effective in WPF if you don’t understand them.  In many ways, dependency properties are the basic nerve system of WPF.  Very little functionality exists in WPF that doesn’t rely on them.
2. XAML – If you don’t like it or are resistant, just suck it up and deal with it.  Seriously. XAML is not only used in WPF, but in Silverlight and WF as well.  Whether it’s XAML, HTML, or plain-old XML, the XML-based development methodologies are here to stay.
3. Binding, binding, and more binding – I can’t even begin to stress how important it is to understand WPF data binding. You simply can’t develop with WPF without it and it takes more than a basic understanding to use it effectively.  You genuinely need to understand the hows and whys or else you’ll spend more time debugging your bindings than just about anything else.  Even if you actually do grok WPF data binding, you’ll still probably spend a significant slice of your debugging time fixing and diagnosing your bindings.
4. Routed Events – WPF handles events differently than other technologies, introducing the concepts of “bubbling” and “tunneling” to event handling.  While you can still handle events the old way, you shouldn’t. Trust me on this one. Routed events will ultimately make your life easier than you can imagine, at least as far as event handling is concerned.
5. Commands – Again, you can do things the “old way” but Commanding solves a number of problems, particularly aiding in the best practice of separation of concerns and encapsulation. The command pattern is somewhat different in WPF than what you may be used to, so it’s best not to assume that you know how it works already (with WPF) which is why it’s on this list.
6. Layout, Measuring, and Arranging – WPF lays out controls and children using very specific rules and principles.  While a comprehensive understanding isn’t required unless you’re writing your own controls, you still need to get a handle on how measuring and arranging works and what is done during each phase. This will really help when WPF puts something where you aren’t expecting and you’ll know where to look for a solution.
7. WPF Threading – Yes, I’m serious. If you’re like many programmers, you’ve avoided threading topics as being either too esoteric or more “bare metal” than you need to deal with. I get that. Business application developers have historically had no concern for threading because we typically deal with “fast enough” performance. WPF changes that, seriously.  It doesn’t change the practice of “fast enough” for business applications, but it rigidly requires all updates to UI objects be made from the UI thread. Again, I realize this isn’t a problem for the vast majority of programs. But I promise that at some point when you don’t have time to study a new topic, you’ll be using some asynchronous API and will try to make a change to a UI element from another thread and WPF simply will not let you. It will happen, I assure you. Asynchronous API’s are becoming the norm and unless your applications never interact with the outside world, you’ll be using one at some point.  It’s better to know what the Dispatcher is, how it works so you don’t have to take a crash course in WPF threading when you can least afford to spend the time to do so.
8. Styles & Templates – Fortunately, WPF’s implementation of styles is pretty straight forward. But, like so much of WPF, it’s different than what you’re going to be used to and you absolutely must know how they work. Unlike most of CSS, WPF styles allow you to dramatically affect behavior as well as appearance and that’s why they’re so crucial. Templates (especially Data Templates) also affect behavior and appearance but in a different (though complementary) way. Both are integral to almost every WPF application.
9. Triggers – While Microsoft includes them in with styles & templates, I think triggers deserve mention on their own.  Yes, it’s through triggers that styles and templates can manipulate your controls, they’re important enough to require study on their own. In my mind, triggers are like declarative event handlers that can be put pretty much anywhere without having to worry about the actual event handling plumbing itself. Triggers will also be the means by which you do any animation and a variety of other tasks.
10. Resources – You must understand how resources work. I can’t say it any more simply than that.  Resources are such an integral part of WPF, you will use them in every single application you write and almost every single XAML file and much code as well. More than anything in WPF, resources tie your application together.

Obviously, this isn’t an all-encompassing list. There are certainly more topics that you need to know, not the least of which being the myriad of WPF controls, deployment, printing, and so forth.  But I can honestly say that without knowing and truly understanding the 10 concepts I’ve outlined above, you’re doing yourself, your customers, and (if applicable) your employer a grave disservice by not being the WPF expert you could be.

And don’t misunderstand me, either. Knowing these concepts only provide the foundation for so much more you’ll have to learn through experience. My grok-list is the beginning, not the end. But if you do grok these concepts and technologies, I promise you that you’re well on your way to being the expert you want to be.

If you’re unaware, StringFormat allows you to bring the String.Format capability to WPF binding and is particularly useful in MultiBinding scenarios.  If you search through the internet, you’ll see many examples of people using TextBox.Text and TextBlock.Text with MultiBinding, such as:

It’s all good, right?  Well, guess what happens when you try to use similar code in Visual Studio:

Oh No!  Right?

Wrong!

It turns out that in spite of the error, the code works just fine.  Needless to say, I’ll be reporting this bug. But until it’s fixed, it’s wise to remember that you can’t always trust inline syntax checking and to do your homework before deciding to abandon a proven technique.

Mission accomplished! 

I made a number of Silverlight controls and small apps and I was very pleased with how easy that translation was.  Initially, i was going to make an Amazon widget, which I may still do at some point, but I abandoned it about 3 hours into doing so because by that time, I’d proven to myself that I could easily take what I know in WPF and downgrade them into Silverlight and what remained for that widget was more fine tuning than development and didn’t serve to be a test of my skills.

So I chose to venture into other areas of Silverlight and with very little exception, I found that WPF skills do scale down to SL quite well.

I know some Silverlight people might object to my terminology such as “downgrade” and “scale down” but let’s be realistic.  That’s what it is.  There is so much you can do in WPF and do it more easily than you can in Silverlight that detailing the differences would be far beyond the scope of this post or my blog (at least for now).  Remember that from the outset, Silverlight was intended to be Windows Presentation Framework, Everywhere.  And to a large degree, that’s what it is.

The bottom line for me is that I can do both with equal aplomb.  There are nuances to each, but even those are becoming less obvious.  For instance, Silverlight uses “states” where WPF does not.  Or does it?

WPF version 4 is now in Beta 2.  One of the many things that have been added in WPF version 4 is the official inclusion of the Visual State Manager.  I say “official” because it’s been available to developers of WPF for quite some time, but it’s an out-of-band download in the WPF Toolkit.

Convergence is the order of the day in what I like to call the XAML-space.  Many WPF developers felt slighted at PDC 09 because of the prominence of Silverlight 4 and the complete absence of WPF in both keynotes.  I even saw many people on Twitter saying that “WPF is dead” though I don’t agree.  The technologies are coming closer together and I find it ironic that what some people are saying is “dead” is actually closer to the WPF/Everywhere vision that was originally intended.

Having said that, I think that Silverlight is still a niche product and should be treated as such.  Unless you have cross-platform concerns (MS still owns over 90% of the desktops) or are going to need the expected future Silverlight on mobile, WPF is still the best choice for the desktop.

Remember, to the man with a hammer, everything looks like a nail.  Just because you know web application development doesn’t mean that every application should be a web application.

From a layout perspective, Silverlight 3 is very similar to what I would do in WPF, but it’s much more basic.  You can do many of the same things, but with Sl, it’s pretty scaled down.  By this I mean that WPF is a richer framework and handles some of the details that you otherwise have to do manually in Silverlight.

One thing I’ve noticed is that Silverlight is very lean with its overloaded constructors.  I’m not complaining, it’s an observation.  I’ll give a real example.

In WPF, I could make a rotate transformation like this:

  child.RenderTransform = new RotateTransform((angle * 180 / Math.PI));

The problem  with doing that in Silverlight is that RotateTransform only has the default constructor.  Fortunately, C# 3 included Object Initializers, so the alternate syntax I have to use is completely painless:

  child.RenderTransform = new RotateTransform()
       { Angle = (angle * 180 / Math.PI) };

How awesome is that?

So you still have the benefit of a lighter footprint without the overloaded constructors (which are just get/set anyway in this case), but still painlessly instantiate and initialize the object.

There needs to be a word of caution to newer programmers.  Don’t assume that you can universally bypass all overloaded constructers using Object Initialization as I’ve done above.  While a significant number of such constructors are nothing more than get/set convenience mechanisms, this is not the case every time.

Object Initialization is easier to read than a parameterized, overloaded constructor.  Just don’t forget that constructors can (and often) do more than just initialize properties.

Know your code!