Robert A. Heinlein defined the word grok as:

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.

Popularity: 100%

One of the features introduced to WPF in version 3.5 SP1 is the StringFormat property.

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.

Popularity: 23%

Well, I finished my experiment with Silverlight, specifically Silverlight 3.  If you recall, the aim was prove to myself that I could translate my WPF skills into Silverlight and how quickly.

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.

Popularity: 16%

1. You get walk into the kitchen and fix your own food when you realize that PDC doesn’t have breakfast. ( Right, @timheuer?  )
2. No “Genius BO” to have to suffer through.  You know who I mean.  You’re sitting behind a guy so brilliant that he could write a new programming language in its entirety on his laptop in during the keynote but apparently can’t comprehend the nuances of personal hygiene.
3. You can threaten Ray Ozzie out loud if he says the word “Cloud” just one more time without having to miss the rest of PDC due to your sudden but imminent incarceration.
4. You get to experience the joy of your two year old coming into your home office during the keynote and asking you, “doin, daddy? Watching tv on puter?”
5. You can get the poppy seed from the bagel you got from your kitchen (see #1) unstuck without someone next to you saying, “STOP SUCKING YOUR TEETH!”
6. Real Internet access.  ‘nuff said.
7. Your body and brain thinks it’s 11:30 because guess what?  It really IS 11:30!
8. You can watch the entire speech without having to decide whether to leave early so you can a good spot in line at Starbucks.*
9. The “Ray Ozzie Drinking Game”.  You can take a drink* every time he said “Cloud” without getting arrested and pass out in your own comfortable chair.
10. When Ray gets boring (and he will), you can hop on over to YouTube and watch Steve Ballmer be not boring.

Popularity: 10%

I’ve been busy on my Silverlight test control and it’s been more fun than I’d expected and it’s actually been a lot easier than I’d expected, too.  So what I’ve been doing is delving into some of the more internal differences to extend what I’d originally planned further.

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!

Popularity: 7%