8 quirks Windows 8 XAML developers should understand before starting their Metro app

It’s no secret, I love XAML. I write XAML, I talk about XAML, I dream in XAML. Sometimes that’s true – especially in the middle of a project. Sometimes people misconstrue that I don’t like HTML as a result, but as a father of three daughters, I can assure you picking favorites isn’t a requirement – even if I have a favorite. ;) But as a Metro developer, there are some things XAML developers should know that will save them serious time. I wish I had this list to start!

Look, this blog is not about complaining. There is no time for that. We need to get building. This is about saving XAML developers time by letting them know the deltas between their previous XAML development experience and what to expect in Metro. Metro XAML is new, right? Yeah - it’s still in beta as I write this. WPF is a decade old and SL is half that. They have a head start and Metro XAML is winding up. In the meantime, I let’s help each other save time. 

PS: remember when Silverlight was only JavaScript? Things enhance! Meanwhile it is what it is. Don’t waste cycles complaining. Build with what you have!

1. The binding Mode is not TwoWay by default. OneWay is, even for TextBoxes. That means Mode=TwoWay needs to become something you type by default. Otherwise, you might start thinking that simple binding does not work when it really works just fine.
2. The ImageBrush’s TileMode is missing because TileBrush is missing. The RadialGradientBrush and VisualBrush are missing. You can burn hours looking for these (like I did). As a result, you will be using more images than you typically would in your designs.
3. There is no ability to PriorityBinding or MultiBinding in Metro (this was also true in SL). Combine that with missing StringFormat and TargetNullValue, though, and you will be using more converters than you might otherwise. Leverage MVVM for formatting, too.
4. Like Silverlight, Loaded is the only RoutedEvent supported in EventTriggers. The error when trying any other event is confusing. In the end, it means most of your animation will be handled through VisualStates more than animating the style.
5. At least in the Release Candidate, the editor reports a WindowsUIXamlBindingWrapper exception when attempting to bind anything to a control’s DataContext. This is only a design-time issue; You can continue developing – but with lots of blue underlines.
6. It is not possible to bind the ColumnSpan or RowSpan of a DataGridViewItem to any value inside the DataGrid’s ItemTemplate or DataContext for to support VariableSizedWrapGrid. Instead, you must inherit from GridView, overriding PrepareContainerForItemOverride(). Note: I will blog about this one soon because it is complicated.
7. To animate properties that cannot be hardware accelerated, you must set EnableDependentAnimation which explicitly allows this, and acknowledges the resulting animation is CPU-based. Otherwise, your animations are ignored (no error).
8. There is a new method argument property called CallerMemberNameAttribute (you might not have even known that arguments could have their own attributes) which sniffs out the calling method or property’s name. This is useful to implement INotifyPropertyChanged. Cool.

Now for the speed round!

1. To implement a Flyout you need to use the Popup control
2. To implement a Flyout/Popup you need to write the “placement” logic
3. RequestedTheme in App.xaml cannot be set per-page
4. Search for Callisto if you are looking for a date picker
5. You cannot debug bindings like in SL5 (commonly asked)

There are more, I know.
Do you have a list?