Review: WPF Unleashed By Adam Nathan

I recently had the chance to read WPF
by Adam Nathan.




I can’t imagine a better book to
learn WPF for developers with a good win32/GDI/Windows Forms background. If you
are not already experienced in these fields, then you’ll certainly find this
book overwhelming.


What I really enjoyed is that the
author has a mature vision about WPF although we are still in the early days of
this platform. What I mean by mature vision is that the book is full of non
trivial tips and also contains a lot of advanced remarks that shed lights on
implementation details.


WPF is still young from MS clients
point of view, but for MSFT insiders, WPF is 6 or 7 years old (or even older?!
btw I would like to know the history of the WPF development). I remember Don
Box introducing XAML 4 years ago during the PDC 2003 KeyNote. Adam is a senior
software development engineer in Microsoft’s .NET Developer Division since
1999, hence the unique vision provided in the book.


The author did also a great job at
underlining the intentions behind each part of WPF. As a former technical
, I consider that explaining the intentions surrounding a technical
subject as the most important part of writing. Technology is all about
intentions! You won’t do anything good with an API as long as you don’t
understand the intentions that motivated the engineers who developed it. In my
opinion, MSDN often lacks intentions and it is its biggest flaw (although this
point got a bit better in the last years).


Another good point is that the book comes
with an excellent 50 pages introduction about WPF 3D done by Daniel Lehenbauer, the Lead
Developer Responsible for WPF 3D. Here also, you can feel that each remark and
each tip provided will be a great help once you’ll have to use WPF 3D in the


Finally, WPF Unleashed layout is colorful. It certainly makes the reading more pleasant. This particular details generated many talks.


WPF Unleashed is a great book, but
WPF is a fantastic technology. I’m really looking forward using it in my own
developments. Here are some rambling about some cool details that positively surprised me
as a win32/GDI/Windows Forms developer:


  • Most of WPF code will be XAML
    declarative code and not C# or VB.NET procedural code. XAML is a
    general-purpose declarative language based on XML. Although it is heavily
    used by WPF, some others framework such as Windows Workflow Fundation use
    XAML and you can easily use it to handle your own scenarios. XAML code
    doesn’t compile to IL or C# or VB.NET code but to a binary form (the BAML
    ). BAML has the double advantage over XML that it yields lighter
    documents and that BAML documents can be parsed more quickly. Concretely,
    most of XAML code will be automatically generated by tools. There is no
    doubt that this XML format will be easier to parse than the messy Windows
    Forms generated code. Hence, I expect that XAML editors such as the
    upcoming Microsoft Expression Blend will be much more reliable than the
    Windows Forms ones.
  • Windows Forms heavily relies on
    the notion of .NET properties. The engineers of WPF thought that .NET
    properties were not enough to handle common WPF scenarios and they
    introduced Dependency
    . The value of a Dependency Property depends on one or
    several providers for determining its value at any point of time. For
    example, the notion of WPF animation continuously modifies the value of a
    Dependency property to move or rotate an UI object. Dependency Property is
    the corner-stone to provide declaratively (in XAML) your own logic on
    value change notifications. Dependency Property is also great to handle
    inheritance scenario such as: the font of a panel have been changed, which
    control child’ font should be updated?
  • WPF comes with an entire new
    API to draw things on the screen. The main difference with the GDI API is
    that WPF is a completely retained mode
    graphics system rather than an immediate mode
    graphics system as GDI. Basically, in immediate mode it is your
    responsibility to draw the correct pixels when a region of the screen is
    invalidated (hence the famous WM_PAINT and OnPaint). In retained mode you
    just have to describe higher-level concepts such as “place a 10×10 blue
    square at (0,0)”. Clearly retained mode is a simpler way to code complex
    UI scenarios and it also represents the magic that makes WPF a 100% vector
    based framework.
  • WPF relies heavily on the
    logical tree vs. visual trees paradigms. Logical tree is the well know controls
    tree (a Panel contains 2 GroupBoxes that each contains two Buttons and a Textbox…).
    Developers will be mainly concerned by the logical tree. The visual tree
    is the visual representation of things that will be displayed on screen by
    the retained mode graphics engine. Although a ListBox is logically a
    single control its default visual tree representation is composed of more
    primitive WPF elements such as a Border, one or two scrollbars… In WPF the
    visual tree is decoupled from the logical tree. Thus it is easy to do
    crazy things such as displaying items of your ListBox on the faces of a
    rotating 3D polygon.


As Adam pinpoints in his
introduction, WPF is the definitive technology to allow doing UI that looks
like what you see in the Hollywood movies, such as slick 3D animations when you
print a document or when you send a mail. Usability issues aside, Hollywood has
been telling us for a long time that software in the real world isn’t as
compelling as it should be.

This entry was posted in Featured. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Patrick Smacchia

    We estimate that some part of the UI could gain from WPF feature. However, as you might know we already did a point on implementing tricky (and useful) effects (zoom, anim…) with GDI+ and that allow us to wait a bit.

    Also, we must take account of the fact that the .NET framework 3 (or more) should be installed, which is not the case by now on most pro machine.

    Finaly I’m a bit skeptical about WPF performance and wait about feedback. Using SetPixel()/GetPixel() WindowForms API takes 100 times more perf than playing directly with bitmap in unsafe mode, I hope that WPF has been more profiled than Windows Forms (on the other hand WPF is able to harness GPU perf…)

    But it is definitely a good idea that we keep for the future.

  • Fabrice

    So, now that you have redesigned NDepend’s GUI and know WPF, will NDepend 3 be in WPF?