Sometimes you have a color in XAML and want to use it in c#. In other words you want to translate something like:
Border.Background = …something…
So you start looking for an IValueConverter that create a color from a RGB string, or translate the hex values to decimal, etc… STOP it!
All you need is:
Border.Background = new SolidColorBrush(
Color.FromArgb(0xaa, 0x0f, 0xcc, 0x1b));
Ok, it may sound stupid, but you never can tell…
Some months ago I read in a blog post that Silverlight ate WPF from the inside. I had a good laugh and thought it was the most foolish thing I’ve read in a while. I even posted a comment that (thankfully) never got published. Having worked extensively with both WPF and Silverlight I thought the two things were not even remotely comparable. While WPF provided great power, Silverlight was full of limitations and getting any real work done was frustrating and painful.
Turns out I was wrong. Completely wrong! This week I attended TechDays (the small version of MIX that Microsoft does in European countries) and while nobody says it explicitly, the strategy at Redmond seems pretty clear. Silverlight is progressing at an impressive pace and WPF is not getting many exciting improvements. The gap is still there (still large to say the truth), but seeing SL reach and eat WPF is not that difficult. I think MS is pushing in that direction with all their forces.
Out of the browser was almost a gimmick in SL3, but with SL4 they revealed their cards: they added so many features (even COM support when running in Windows) that it’s now doable to build a desktop application entirely based on SL. You can even deploy it directly on the desktop without any browser interaction.
I’m pretty sure it will only take a few of years for Silverlight to be the Windows UI library, with the big bonus of true multiplatform, small runtime and web deployment with a single codebase. WPF won’t loose anything as it will just be part of Silverlight.
This is the future I think. Unless I’m completely wrong again.