What did you find hardest to understand when learning WPF

What bit of WPF did you

• find hardest to understand
• or misunderstood for longest

and how did you understand it in the end (please provide links etc).

(I am asking this to guide my learning of WPF)

Sorry this got so long ... hopefully it is helpful! One thing I would mention is that these are the concepts/things that tripped me up, I'm not sure if I would use it as an itemized list of what to study if you are just starting out. I would dive in on some books, read through a lot of blogs (Josh Smith, Dr. WPF), and just in general, dive in and try things out in little projects.

Core Concepts

• The Logical and Visual Trees (links: 1)

  Understanding the different trees in WPF. In particular, understanding the logical tree versus the visual tree and how elements in the logical tree gets expanded into the visual tree by way of data templates, control templates, etc.

• The Dependency Property System (links: 1, 2)

  Understanding the whole dependency property system in WPF is much bigger than it first looks. Sure, it is easy to create a quick dependency property and then use it to empower other WPF concepts like data binding and animation, but then it begins.

  There are normal dependency properties and then there are attached dependency properties. There are a bunch of different ways to register them all and a bunch of different metadata options that you can set.

  Understanding why it is called a dependency property, for that matter, took me some time. That is, understanding that the value of property comes from many different sources (the property depends on these value providers) and that there is an order of precedence/algorithm for how the final property value at any given time gets set.

• Routed Events (links: 1, 2)

  Understanding how they can be bubbling, routing, or direct. Understanding that you can also have attached routed events (versus just attaching an event handler to an event that has routed up the visual tree).

  Tips

  Chapter 3 in Adam Nathan's WPF Unleashed is an awesome chapter that covers these important new concepts and one that you should read, work on a project, and then read again.

  Dr. WPF's snippets are a great way to learn about dependency properties, routed events, and commands.

Graphical Concepts (links: 1)

• Resolution Independence (links: 1, 2)

  WPF brings all the benefits of resoultion independence (you specify everything with device indepenent pixels) but this also brings some headaches that you need to solve. Most notably, is getting things to look sharp when you want them to by taking advantage of pixel snapping, by setting guidelines, etc.

• Retained Mode vs. Immediate Mode

  WPF has a retained mode drawing subsystem, meaning that it keeps track of the drawing instructions and caches them for later use. This can be a performance problem if you are trying to build something that has a lot of visuals that are all updating at once.

• Controls, Elements, Visuals (links: 1)

  Understanding what each thing in the WPF hierarchy does for you and understanding the weight it brings in performance. In particular, do you use a Control that you can retemplate, restyle, and more ... or do you need something ultra-light (like programing against the Visual layer) so that you can drive it hard and fast.

  Tips

  Chris Sells and Ian Griffiths have a great appendix at the back of their Programming WPF book that talks about the different types in the WPF API, where they fit in the hierarchy, and what value they bring.

WPF Patterns

• Model-View-ViewModel (MVVM) Pattern (links: 1)

  The MVVM pattern has already been mentioned as helping one to start doing things the WPF way. I can't agree more. Instead of filling controls with data, you start transforming data into visuals (through data templates).

• Attached Property Behavior Pattern (links: 1, 2, 3)

  WPF is extensible like no other API. Utilizing attached properties, you can build in additional behavior in a very elegant manner and where you thought you might have been stuck.

WPF != Windows Forms

I know someone already mentioned this but I want to agree emphatically. There are so many new and different concepts, you really do have to unlearn quite a few things and approach solving problems from a completely different angle. As an example, Windows Forms is an immediate mode drawing subsystem while WPF is a retained mode one (above).

The Many, Many Ways To Do Things in WPF

This is a funny thing to bring up, but because there is so many ways to do something in WPF, it is almost paralyzing. Which way is the right way to do things? Is it this? Is it that? I have had to get over a fear of doing it the wrong way, to just jump in, and learn from my mistakes.

WPF is not WinForms. Most, if not all, of the common strategies you use to accomplish tasks in WinForms are the wrong (or least efficient) way in WPF. Commands, Dependency Properties, Binding, Templating, etc, all will be less useful if you adopt a WinForms mindset.

Currently we're in the development of a large visualization application. As seasoned WinForms programmers, our first cut at the display of multidimensional data precomputed thousands of visual elements. A slider would traverse the dimensions of the visual elements using a callback. No data would be loaded beyond the initial setup. This had very poor performance.

Switching to thousands of bindings with data converters, on only a few hundred visual elements, with the data being loaded and recomputed on the fly. This resulted in an order of magnitude improvement of performance. It was almost inconceivable that thousands of bindings would be faster than thousands of precomputed visual elements, but such is the case in WPF.

"From WinForm to WPF: A Quick Reference Guide" may be useful.

I'd say the hardest points when I started learning WPF were :

• Styles and templates: it took me a while to understand when to use which, and how they interact with each other
• Complex bindings with RelativeSource, converters...
• Triggers : I still get confused sometimes about where I should use DataTriggers, Triggers or EventTriggers...
• Mechanisms of dependency properties and attached properties
• The way routed events work

There are many little things that can seem difficult at first if you have experience with Windows Forms. You need to unlearn a lot of things, and switch to a very different mental model of the UI structure.

At first I started to code as I did in Windows Forms, with lots of code-behind, but that was definitely not the right way. The MVVM pattern really helped me to get into the WPF "philosophy"...

My main source of documentation for learning WPF was of course MSDN, where you can find most answers if you know how to look. I also learned a lot of things on the following blogs :

• Josh Smith on WPF

• JAPF

• Lester's WPF blog

• C# Disciples

• Karl on WPF

Dependency Properties took a while. Here's a nice article, and another that helped me with this new concept.

The second article contained the following paragraph that really clarified a few questions I had.

> A key value of the Dependency > Properties system was the ability to > build properties that automatically > notify any registered interested party > each time the value of the property > changes. This free, painless and > automatic implementation of the > observer pattern is tremendously > powerful and greatly reduces the > burden on the client programmer (in > fact, the data-binding system depends > on it!).

More generally, I have also found that prior experience with web development (browser UI in particular) to be very useful in "getting" WPF. It is more about the mindset it allows you to bring to WPF, compared with someone who has only ever worked with Windows Forms or other rich client applications.

Some more obvious parallels from the web world are CSS, flowing layouts, jQuery animation, event bubbling/routing and just being comfortable with the extensive browser and DHTML object models.

MMVM is a pretty tricky thing to learn. However i think its one of best things about WPF. It takes a lot of studying to get it in because they are a lot of scenarios where it is a bit difficult to implement.

As Thomas pointed out there is a lot of great material out there by the like of Josh Smith and others. Be carefull though WPF is very easy to study about but you have to use it say writing an application to see various scenarios in practice.

Data Templating (and Control Templating for that matter).

On the surface, it's reasonably straightforward, but once you start trying to setup binding between different XAML files, it can become seriously confusing.

I suppose that I finally managed to get a decent grasp through it by going through a lot of MSDN docs, but moreover, trial and error. Playing around with things is usually the best way to learn any technology.

I still cannot specify target property in animation without cheat-sheet:

<DoubleAnimation
Storyboard.TargetProperty=
"(UIElement.RenderTransform).(TransformGroup.Children)[0].(ScaleTransform.ScaleY)" 
To="1.2" Duration="0:0:.2" />

Let's take it from beginners view. I'm using simple editor like KaXML or Sharpdevelop for WPF development. and i find that i can't proceed with database development without Database grid component. So it is not like Windows forms. Start searching for commercial database grid component. and in defense people will say it is not hardest thing or limitation.

You've to work with C# files or other language files supported by .NET Framework for serious application development. If that is not makes it problematic so, why do i need to use it at first place. I'm happy with C# why do i need to use WPF ?

Hardest things so far :

1. Data binding,
2. Dependency on another language (C# for example),
3. Graphics capability.

Layout is different in WPF see http://blogs.msdn.com/b/wpfsldesigner/archive/2010/06/03/layout-techniques-for-windows-forms-developers.aspx for how to use the layout editor

Biggest nuisance is : You can't get just another developer to work on WPF app done by a pro. This is not the case with WinForms and Asp.net where any one can work with very little problems. This is a major issue.

The differences in Binding syntax was one; i.e. when to use Binding and when to use StaticResource/DynamicResource. When I was first learning WPF, I kept getting the two mixed up.

The different forms of DP and attached properties were also hard to understand at first.

Reading through books and understanding the stuff is one thing and applying them in your project is another. I was creating a relatively simple Contact List control just like in Outlook and came across many small but noticeable learning curves.

1. First, Templating seems simple as you are reading but it get trickier when you play with it. Just setting the background color of a user control when a text box gets focus was challenging. It turned out that I had to use DataTrigger (who would have thought).
2. Using a wrapper as an ItemsPanel for List box all of a sudden became a challenge as it was not arranging the items (you have to play with it).
3. Definitely RelativeSource in Binding.

Basically being able to bind controls in your template (from parent to child and vise versa) is a good learning curve.

My advice. Write a small app and you'll see thing coming together.