I was surprised to learn that Xaml for Windows Store applications does not have support for Triggers. Triggers within WPF (DataTriggers, EventTriggers) are a simple way to introduce interactivity to a user control such as changing the display properties when an event or data condition is satisfied. Since Triggers are declared using Xaml syntax, functional behavior can be introduced by modifying a style rather than writing code in the code-behind.
In recent years however, WPF has introduced the Visual State Manager (VSM) concept, which originally grew out of the SilverLight and WPF Toolkits before being rolled into .NET 4.0. The Visual State Manager is much easier to use because it groups previously unrelated triggers into more meaningful semantic states (MouseOver, Pressed, Normal, Disabled, etc). Triggers have played a less important role in WPF development since this time, but there were still occasions where a Data or Event Trigger made sense.
Unfortunately, triggers were not included in Xaml for Window Store applications. (Technically, EventTrigger is included but it only supports the FrameworkElement.Loaded event). So where does this leave us?
Here’s a few options:
- Implement a custom Control with specialized Visual States. Obviously not ideal but probably the most technically correct implementation.
- Implement an attached behavior (an attached property that listens to control events).
- Leverage ports of the Expression Blend Behaviors (System.Windows.Interactivity and Microsoft.Expression.Interactivity). There are a few promising starts, including Windows.UI.Interactivity, which looks like a direct port of System.Windows.Interactivity.
Personally, I’m a fan of the expression Blend Behaviors, especially the InvokeCommandAction which is immensely useful when building MVVM applications. I’ll post more about these with some examples soon.
Until then, happy coding.