Menu
The difficulty with learning WPF is not so much the API as the model. It's a very different mental model than you'd use with something like Windows Forms. Rather than writing methods that imperatively populate a UI element, you generally data bind to properties on an object.
Yes WPF is worth learning. If you look at the use of WPF currently it is the preferred approach to develop desktop applications on windows. It is used by lot big enterprises ,so that itself demonstrates the popularity 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 :
RelativeSource, converters...DataTriggers, Triggers or EventTriggers...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 :
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With