Yesterday I started a thread on the WPF Forum which has turned out to be rather interesting. I won’t go into too much detail about it in this post, but here’s the general gist. Normally the WPF data binding system requires a data object to send out notifications when one of its properties has changed so that the new value can be displayed in the UI. There are three ways to do this:

Raise a PropertyNameChanged event when a property has been changed (ex. Raise a NameChanged event when the Name property of an object is set).

Implement INotifyPropertyChanged on the data object and raise its PropertyChanged event when a property is set to a new value.

Derive the business object’s class from DependencyObject and implement the property as a dependency property. DPs handle all of the change notification work for you.

As described on the thread I discovered an oddity where the new value of a property was appearing in the user interface, even though the data object emitted no property change notifications. The answer to this mystery, as Douglas Stockwell figured out, has to do with the fact that the data binding system uses PropertyDescriptors to set the value of a property on the source object. PropertyDescriptors have built-in value change notifications which they raise when setting a property on an object. The binding system listens for change notifications sent out by PropertyDescriptors and, when they are raised, will update other Bindings which are bound to the same property on the source object.

For more information about this quirky, yet interesting, aspect of the WPF binding system check it out here.

Anderson was one of the chief architects on the WPF team at Microsoft. He was involved with many design iterations of the platform over the course of several years. As a result, the depth and insight into the platform which his book offers is truly astounding. He does not only explain what you can do with WPF, but explains why the features of the platform were designed the way they were.

Anderson will even discuss how some features were initially conceived but why the initial design did not work well, and how the final design overcomes those problems. For example, the styling system in WPF initially used a miniature query language to specify how a style should be applied to elements in a UI. He explains the shortcomings of that model and why the styling system we are all familiar with is better. That is priceless information for anyone who is serious about understanding the Windows Presentation Foundation.

Toward the beginning of the book Anderson lists the three overarching principles behind the design of WPF: element composition, rich content everywhere, and a simple programming model. Throughout the rest of the book he demonstrates how the various functional areas in the platform adhere to those guiding principles. Looking at the platform from that perspective clarified a lot of things for me. I found it especially interesting how he discusses the command model as a means of simplifying the programming model of a composition-based architecture.

In my review of “Windows Presentation Foundation Unleashed” I stated that “I just can’t go back to reading black-and-white books about WPF.” I guess I was wrong! The images in “Essential Windows Presentation Foundation” are black-and-white, but it didn’t bother me one bit. Anderson’s book is not done any injustice by black-and-white images. The content of the book is so interesting, and well presented, that the images were not very important to me.

I have only one qualm with Anderson’s book. I was hoping that it would have an in-depth explanation of the Media Integration Layer (MIL). There still seems to be a big gaping hole in general around this topic, not only in Anderson’s book. It would have been great if he really dove deep into how drawing instructions are sent to the render thread, how changes to the visual tree are communicated to the MIL representation of the UI, how this works in a remote desktop scenario, etc. Unfortunately I guess I’ll have to wait for someone else to demystify that topic.

To recap, I think that “Essential Windows Presentation Foundation” is a must-read for WPF developers. Take my word for it, just buy the book and start reading it.

XAML is simple, which is a good thing. It is just an XML-based language used to declare objects and the relationships between them. One side effect of being simple is that it can be verbose. This cumbersome verbosity was one of the main reasons why the concept of markup extensions was introduced. A markup extension can be used to turn many lines of XAML into one concise expression, as we will see later on.

Another side effect of XAML’s simplicity is that it does not have any “built in” knowledge of common artifacts used by WPF or the CLR; such as resource references, data binding, a null value, arrays, static members of a class, etc. Since XAML can be an integral part of application development there needs to be some way for developers to express those ideas in it. This is another major reason why markup extensions were added to Microsoft’s implementation of XAML.

Here is an example of several markup extensions put to use (in this demo, the StackPanel’s DataContext was set in the code-behind to a Person object):

All markup extensions derive from the abstract MarkupExtension class and override its ProvideValue method. The naming convention is to append the word Extension to the subclass’s name (only the Binding class does not follow the pattern). The XAML parser allows markup extensions to be created within {curly braces} and it also allows you to omit the Extension suffix when using a markup extension, if you want to.

In the XAML above, take a look at the TextBox’s Text property, and the CheckBox’s IsChecked property. They both use the Binding markup extension to bind their values to a property on the data context (a Person object). The Binding associated with the TextBox’s Text property is much less verbose than the IsChecked Binding. The verbosity reduction would be even greater if the Binding configuration was more elaborate.

If you want to see what this ugly demo app looks like, click on the thumbnail image here:

Chris Cavanagh, the man who came in second place in The WPF Challenge for his WPF Physics demo, is at it again. This time he has built a Silverlight 1.1 app on top of a physics engine. I’m amazed that Silverlight can handle this type of scenario! As Chris points out in his blog post about the demo app, there seems to be some performance issues in Silverlight which cause the animations to “freeze” for a short time. Other than that, the demo is very cool! Check it out here: http://chriscavanagh.wordpress.com/2007/05/22/silverlight-11-2d-physics/