Charlie Robbins

In the last week, my daily reading has pointed me to a lot of great free online resources for Silverlight. I'm surprised how many of the code samples available are based on System.Windows.Interactivity behaviors. We've come a long way since it was called the Remora pattern.

Silverlight Resources

• Farseer Physics Engine
• Expression Blend Gallery
• Silverlight Contrib

The great thing about releasing behaviors is that designers can use them in Blend without ever needing to touch the code. A sample I came across that uses the Farseer Physics Engine was built entirely in Blend 3! How cool is that?

So today I came across a very interesting post about "Fluid Dynamic in Silverlight 3" using WriteableBitmap. WritableBitmap is a new feature in Silverlight 3 and from what I've seen greatly improves the rendering performance of complex pixel effects. It's a simple way to host a raster graphics surface (i.e. an area in which every pixel is re-drawn at every refresh) in a retained graphics system (like Silverlight). Ok so great, awesome tutorial. What's the problem?

The problem is that the blogger in question, Rick Barraza, decided not to share his code for whatever reason. Having a desire to understand how his effect works and as a supporter of open source software I was naturally frustrated. However, luckily I knew the inner workings of Silverlight 3 and I was able to get the code running on my own machine within a few minutes.

I was recently working on a particularly frustrating and repetitive issue for WPF developers: Custom Window Chrome. I mention that it is frustrating merely because it's something that seems trivial but is plagued with gotchas and Win32 hacks. Thankfully, some nice people over at Microsoft have put together a library that takes a lot of the pain out of the problem. It does not solve all the problems however, and that is the purpose of this post of course.

There were two annoying problems that I've seen come up again and again with custom window chrome that I decided to finally remedy once and for all:

1. Reusing Window components such as Min / Max / Close buttons, etc.
2. Getting SizeToContent to work correctly.

The former of the two problems led to a relatively straight-forward custom control with a number of template parts that are available for use. The latter however, was a bit of a tricky problem. You see in the MeasureOverride of the Window it is simple to return the desired size of the child given infinite height and width, but it is impossible to know when the desired height and width of that child changes because it is not a direct child of the Window object itself in the visual tree.