Last Wednesday was a big day around the office because it was the official launch of Blendables V1.  It’s been nine months since we formally launched our Blendables efforts and it’s been a fun ride.  My contributions to V1 are isolated to TimelinePanel (and some work on the samples browser).  I wish I could take credit for more because there are some ingenious controls in there! 

In fact, I’m working on a project right now where, for various reasons, I can’t use any of the Blendables controls and I’ve been amazed by how crippled I feel.  EvalBinding and ElementSnapshot, in particular, have become part of my normal workflow.

So, congrats to the team!  Now on to the next version (yup, it’s already in the works–and promises to be just as handy!).

In the meantime, check out other coverage of the launch here:

Coverage from the Seattle Times
Nate’s Blog
Kurt’s Blog
A nice review of EvalBinding at Planet XAML
Official Press Release

“A three-year study of more than 40 Fortune 500 companies by the research firm Peer Insight found that companies focused on customer-experience design outperformed the S&P 500 by a 10-to-1 margin from 2000 to 2005.”  Get the whole article here.

A really nice way to handle XML data serialization in WPF is to use the XamlWriter and XamlReader classes.  That’s right, XAML isn’t just for UI (or for WPF for that matter).  Basically, you can throw any object at these classes and, assuming you follow a handful of rules (like every class you serialize needs a public, no args constructor), then you end up with a very nice XML representation of that object and you had to do basically no work to get there.  I use this approach to serialize business object data all the time.  It’s super handy.

I consistently run into one issue and just as consistently forget the work around.  So as a note to my future self, I thought I should write it down this time.  The problem is that XAML has only very limited support for generics.  This is a head on collision with the fact that the only thing more convenient than serializing data to XAML is using ObservableCollection<T> for lists of things in those data objects.  I use it all over the place, but it doesn’t play nicely with XamlWriter. 

Fortunately, the fix is easy.  XamlWriter doesn’t have a problem with the construct of a list at all, it just can’t deal with the fact that it’s a generic.  To work around this, then, we just need to create a proper class that derives from ObservableCollection<T>.  So something like this:

public class Customer
{
   ObservableCollection<Order> Orders;
}

…becomes…

public class OrderCollection : ObservableCollection<Order> { }

public class Customer
{
   OrderCollection Orders;
}

And then your up and running again.  I whipped up a little sample app that shows examples of using both XamlReader and XamlWriter to serialize data object to XAML as well as the workaround for ObservableCollection<T>.  You can get it from the link below:

I end up using Blend a lot to create little shapes (like arrows or curves for a reflection) and for a V1 product it’s got a pretty nice path manipulation system. There’s one thing that bugs me, though, and that is the fact that when I rotate or scale the path, it applies a transform instead of actually updating the path data.  Sometimes the transform is what you want (like in an animation), but sometimes you actually want the path data to get updated.

That happened to be this weekend.  I was creating back and forth buttons for new Kaxaml (nearly ready!).  I created an arrow for the back button, but then I needed the reverse version of that arrow for the forward button.  Rotating it, of course, just applied a RenderTrasnform so I ended up with this:

This obviously isn’t what I wanted.  The gradients are whacky.  I could update the gradients and things would probably be hunkydory, but this will ultimately be a button so that means keeping duplicate gradients around for at least 3 states (normal, mouseover and pressed). Also it just leaves the code feeling kind of hacky.

Now there may be a way to to get Blend to just update the path data for you as you manipulate an object, but I don’t know what it is.  So I devised hack that essentially “clears” the transforms and leaves you with clean path data.  It’s easy.

One you have manipulated the path so that it is rotated, skewed, etc. as you like, simply create another object (a small rectangle for example) that fits within the bounds of the original object and then place it on top of the original object in such a way that there is no overlap.

Make sure that the rectangle is void of any transforms.  Next shift select both objects.  Here’s the important part: be sure the select the rectangle last. 

Finally, just choose Object | Combine | Unite from the Menu and voila!, you are back in business. 

This works, obviously, because the Combine action inherits the transforms from the last object that was selected and when we unite these overlapping objects we get a path that is the same as the original.  The other option, I guess, is to do this in Design or Illustrator and then I wouldn’t have this problem.