So I'm glad to announce that the WinFX June CTP has just arrived; you can find the download for Windows XP and Windows Server 2003 here (the next Windows Vista CTP, due imminently, will also include this same release). As you may have heard at TechEd or from Somasegar's blog, we've made the decision to rename WinFX to .NET Framework 3.0. Nothing has changed about the contents of the product or the schedule - it simply reflects the fact that WPF, WCF and WF are a continuation of the .NET platform we've been building for the last five years or so. I highlight it simply because this is the first release that includes the final naming.
From a WPF perspective, there are only a few minor API breaking changes. I'm going through the process of updating some of our demos and samples right now, and so I'll continue to update this entry with any other common issues. Here are the ones that you might hit:
DefaultStyleKeyCurrently, to have your style replace the system theme file, you need to set DefaultStyleKey property to null. We've now made DefaultStyleKey protected so that only component authors can specify the default style key. Instead of setting DefaultStyleKey to null, style authors should now set the new boolean OverridesDefaultStyle property to true.
NavigationWindowNavigationWindow now no longer supports content directly - instead, you'll need to add a <NavigationWindow.Content> element to contain it.
One nice addition to XamlPad that you'll notice when you install the new Windows SDK is a "Show Visual Tree" toolbar button. This is really fun - you can use it to see what the visual tree looks like, based on the logical tree expressed in XAML. This can be really handy when you want to override a default template for something like a button. The property tree explorer also allows you to inspect the properties set on various elements within the visual tree. I love this feature - although I want to spend less time in XamlPad and more in Expression Interactive Designer and Visual Studio, you can't beat a lightweight tool like XamlPad as a sandbox for experimentation. Here's a screenshot to whet your appetite:
I'll continue to update this entry with other breaking changes - feel free to leave a note in the comments if you're struggling to port some code forward because I've not covered it here, and I'll try and find the delta for you.
...this is.
I'm in awe of the cool demo visualizations that Lee Brimelow (author of the well-regarded TheFlashBlog) has put together since he started to experiment with WPF. If you've got Windows Vista Beta 2 or just the WinFX Runtime Components Beta 2 on your machine, check out these:
Anyone else got a great WPF demo they'd like to showcase here? If it's a XAML browser application (XBAP), all the better!
Check out See Windows Vista if you haven't already to see twenty applications that give a glimpse of the new wave of rich client applications that Windows Vista will enable, built on top of the Windows Presentation Foundation. One of the first of these applications to go public is iBloks, which you can now download from their homepage.
If you want to get your own application ready to support Windows Vista, make sure you check out the Windows Vista DevReadiness community site. You'll find information here on the logo requirements for Windows Vista-certified applications as well as tips on how to be compatible with new security features such as User Account Control and the filtering network stack.
I wanted to link to this on10 video, which shows Kevin Gjerstad demonstrating the New York Times reader application. This is a great example of the transformative power of WPF for content sites: the flow content features allow adaptive columnar layout of text and graphics, as opposed to the fixed-width news sites today that waste screen real estate and increase scrolling. Aside from that benefit, you also get embedded fonts that match the "house style", the enhancements to text resolution that are part of the new improved ClearType engine in WPF, and the ability to cache news articles for disconnected reading.
I can't wait for this to be available to the world - it'll be in beta in just a couple of weeks.
The answer might not be what you'd expect.
In XAML, you can express colours in a number of different ways. One option is to use the 24-bit hexadecimal RGB notation that is common in the web, for example: <Ellipse Width="300" Height="100" Fill="#A3BDE2" Stroke="#5C6DBE" StrokeThickness="5" />
WPF has full alpha channel support too, so you can express the hex value as #AARRGGB, as in the following: <Line Stroke="#7F006666" StrokeThickness="10" X1="0" X2="300" Y1="100" Y2="0" />which draws a cyan line of 50% opacity over anything beneath it.
Another available model is scRGB, which allows you to express a colour as four single-precision floating-point numbers, allowing for an ultra-wide gamut of colour representation. One of the nice features of scRGB is that it allows you to express values outside of the RGB range of #000000..#FFFFFF, allowing you to create colours that are "darker than black" or "whiter than white". You might think this is a pretty useless feature, but when it comes to image processing this is very useful in allowing you to retain the fidelity of an image. For example, let's say that you process a photograph of a cloudy sky and pass it through a pipeline that corrects contrast, colour temperature and brightness. Without a colour mapping such as scRGB, it's possible that any step in that pipeline could blow out the detail in the image (perhaps the contrast correction creates whole blocks of the image that are white). By allowing a broader range, even though it can't be displayed on screen, it's possible to maintain that information so that by the time you get to the other end of the pipeline, the brightness correction can use information that would have otherwise been lost to bring all the colours back within a visible range. I digress, anyway.
Here's how you express an scRGB colour in XAML: <Rectangle Stroke="sc#1, 0.6046357, 0.223508522, 0.182969958" Fill="sc#1, 0.7785599, 1, 0" RadiusX="25" RadiusY="25" Width="250" Height="80" StrokeThickness="5" Margin="60" />
The final way to express a colour in XAML is to use named colours, for instance Green, SteelBlue or MediumVioletRed. These colours are the same named colours as are present in HTML or SVG and include a number of quirks and idiosyncrasies that stem from their heritage. For example, the set of named colours isn't evenly spread across the spectrum (there are many red and orange hues against a comparative lack of shades green), and some of the colours have pretty esoteric names that display a lack of cultural awareness by the original author (how many non-US readers can fathom a guess at the colour DodgerBlue represents?). Some are even spelled inconsistently (for example, Gray and DarkGray have the US spelling, whereas LightGrey has the UK spelling).
There's an even stranger phenomenon, however. These colours don't actually originate in HTML - they date still further back than that to the X Window System that originated on UNIX systems. The HTML specification defines sixteen named colours that map onto the basic sixteen colours present in the EGA palette, but the earliest browsers such as Mosaic also supported any of the other X11 named colours, based on their colour representation as defined on X. Unfortunately, some of the original sixteen named colours have different representations to the X11 equivalents, for example Green is represented in X11 in this colour, whereas in HTML it's represented in this colour. The unfortunate result is that Gray is defined as #808080 in HTML, but DarkGray is represented as #A9A9A9, meaning that they're the wrong way around. Since WPF allows the same named colours as HTML for compatibility, the result is that the same idiosyncrasies carry forward. (You can find more information on the full set of X11 colour names and their representations in Wikipedia).
My recommendation therefore is in general to use the hex or scRGB colour representations wherever possible, or you might be surprised by the colours that you pick not matching your expectations!
Here's a short sample that wraps all these elements together: <Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" Margin="30" > <Rectangle Stroke="sc#1, 0.6046357, 0.223508522, 0.182969958" Fill="sc#1, 0.7785599, 1, 0" RadiusX="25" RadiusY="25" Width="250" Height="80" StrokeThickness="5" Canvas.Top="60" Canvas.Left="80"/> <Ellipse Width="300" Height="100" Fill="#A3BDE2" Stroke="#5C6DBE" StrokeThickness="5" /> <Line Stroke="#77006666" StrokeThickness="10" X1="0" X2="300" Y1="100" Y2="0" /> <TextBlock FontFamily="Calibri" FontSize="40" Foreground="DodgerBlue" Canvas.Top="150" Canvas.Left="10"> <Run FontStyle="Italic">This </Run>is Dodger Blue </TextBlock> </Canvas>
and here's how that looks:
(Thanks to Hans Hugli for the inspiration for this article.)