My work has taken me in the direction of WPF once again, which means I have been out searching for good WPF content and examples. Lucky for me his month also appears to have been WPF month, as good content has just fallen into my lap! 

In this post I showcase the best of what I have found over the last month. For those that might be interested I also put any good stuff I find, on various topics, on my del.icio.us; so if you want to stay ahead of the blog posts you can always keep an eye on that list via RSS.

---

The most impressive by far is Family.Show from the boys and girls at Vertigo; who over the years have produced some stunning sample software for Microsoft. Showcasing the possibilities of working with the Microsoft stack.

They not only publish the application but also the code, truly awesome work. If you look at nothing else before you start your WPF project, look at this.

---

I also stumbled upon Kevin's WPF Bag-o-Tricks via the MIX07 sessions; all written by ex-Microsoft employee Kevin Moore, who is a great developer and presenter. He gives a great demonstration of his Bag-o-Tricks in his session called "Windows Presentation Foundation for Developers - Part 2", well worth watching (search for kevin moore to find his session from the MIX sessions web site). Part 1, delivered by Rob Relyea (who has kindly pointed people my way in relation to WPF commands), is interesting for those just starting on the WPF journey.

Some of the old favorites are also there on the MIX sessions talking about related topics, notably Scott Gu, Don Box and Brad Abrams. Don on navigating the web and Brad on all things Silverlight and Scott gives the Keynote.

---

Finally there have been a small number of podcasts (from the Pwop stable) on WPF and Silverlight that are worth your time; in order of preference:

• Catching up with Brad Abrams (more Silverlight than WPF)
• Rocky Lhotka and Anthony Handley on WPF
• WPF Panel Discussion

---

And there we have it. If you have any links or have any comments I'd love to hear from you; either leave a comment on this post or send me an email. Enjoy.

One of the demos I like to give when showing XAML in WPF is the "Live Reflection"; this is where you have a video playing and you show a reflection of the video using a VisualBrush and LinearGradientBrush for the opacity. In WPF the XAML for this would be:

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="LiveReflection" Height="400" Width="400"
    >
 
   
   
     
       
     
     
      
         
         
       
     
     
       
     
   
 

Once compiled this produces an output similar to the following:

 

Naturally, when I first started looking at Silverlight the first thing I wanted to try was reproduce my "Live Reflection" sample. The first stumbling block was that there is no such thing as a VisualBrush in Silverlight.

Did this mean that failed at the first hurdle? Well, no. It is true to say that there is not an equivalent brush to the VisualBrush in Silverlight; there is nothing that will render any part of the visual tree as a brush. However, there is a brush that will render any part of a MediaElement, and this brush also supports transforms. This brush is unique to Silverlight and it is called a VideoBrush.

Next I wrote this XAML in Silverlight:

  xmlns="http://schemas.microsoft.com/client/2007"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  Width="346" Height="516">
                  x:Name="video" Source="Bear.wmv" Stretch="Fill" />

 
   
     
   
   
     
   
   
     
       
       
     
   
 

Once hosted in a browser produces an output similar to the following:

Mission accomplished.

There is a moral to this post; which is that this encounter is not uncommon with many aspects of WPF vs. Silverlight. While there is not always a 1:1 match in Silverlight there usually is a way (with the exception of 3D and Binding, concepts not supported by Silverlight 1.0, 1.1 or v.next from what I can tell, in any way what-so-ever). I have been working closely with Silverlight 1.0, day in day out, for a little over a month now and I am really impressed.

Initially, when my day job involved writing production as opposed to now where I write about writing production code, I dismissed Silverlight 1.0. I really did not fancy writing reams of JavaScript and messing around with a very small subset of a technology that I loved the from moment it was released (WPF if you had not already guessed) - especially with 1.1, meaning C# on the client-side, no JavaScript :-0, hot on it's heals. But over the last few weeks I have come to appreciate what Silverlight 1.0 is and is capable of. While your RIA might be far from easy to write, there is a way. You just have to want to do it.

---

Finally, an apology: to my friends. Yes, this is yet another Live Reflection example that you've had to endure - for that I'm sorry (JP: I am truly, truly sorry to you; you've had to put up with this, and much more from me, more than most - thank you my friend).

So powerful is WPF that you can write, in less than 20 lines of markup (with zero code behind), a simple text editor... with spell checking!

All you need do is put the following XAML into your favourite text editor and compile:

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="SimpleXAMLTextEditor" Height="300" Width="300">
 
   

     
       
       
       
     
   
   
     
       
       
       
     
   
   
 

This produces a very simple application:

 

No code is required because the WPF team have already implemented the standard edit commands[*] for the TextBox and RichTextBox controls. You also get spelling for free by just adding one attribute.

Do the WPF team rock or what!

[*] For more on commands check out my previous post on the subject.

The talk about choosing between boolean values and enums when passing as parameters to a method and offers this advice (§5.7.1, p150):

In general, you should favor using enums where it improves the readability of the client code, especially in commonly used API's. If using enums would add unneeded complexity and actually hurt readability or if the API is very rarely used, Booleans should be preferred.

The reasoning for this is twofold: it's more readable, as the quote states and enums allow your API to expand without breaking the contract of the method. However, there are times where you cannot replace the parameter with an enum, or there will never be another value other than true or false.

Readability is the real issue for me here as I think the extensibility element is easy to architect and deal with, however YMMV, consider this code:

public Customer GetCustomer(int id, bool isDeep){ ... }

This is all well and good - readable, but what about at the call site?

Customer c = GetCustomer(11209, true);

The true value might make sense while you're writing the code and while it's all fresh in your mind; there may even be other developers in your team that might understand what you're up to right off the bat, because it could be a standard convention or something similar - but what about that contractor you've hired for a week, that code you've outsourced to your Indian partners or the poor newbie on your team?

On possible solution is the approach recommended by Steve McConnell in is the following:

bool isDeep = true;
Customer c = GetCustomer(11209, isDeep);

This is a very valid approach, but (and it's a BIG but in my view) requires discipline, code review and forethought on the developer side to be consistent and effective. If you can achieve this in your team then great, you should do it, no questions asked - but how about this as an alternative:

Customer c = GetCustomer(11209, true /*isDeep*/);

The downside to this approach, over the McConnell approach, is that this only works when you have the actual source code - not an approximation like when you use Reflector. Otherwise this additional information is lost, where it would be preserved by creating variables (well, only if the PDB is available for the assembly; otherwise you're in the same place as with the comments approach).

Let me know what you think?