MSDN discourages the use of EventTrigger‘s and really any custom trigger actions but have offered StoryBoard‘s and the VisualStateManager as alternatives.
Q1. Why are triggers being discouraged when they appear to be so useful?
MSDN’s justification seems to be:
EventTrigger and the object.Triggers
property element usage on elements are
supported by Silverlight, but using
this technique is discouraged for
current applications. EventTrigger can
only support a triggering action for
the Loaded event (you name the event
in the EventTrigger.RoutedEvent
property.) This makes an EventTrigger
unsuitable for most run-time
interactions.
So, it’s ok to name the VisualState for the VSM but not ok to name the event? Both are string values that can potentially change, so why is the naming of one worse than the other?
Q2. What is the best practice approach to animating an object’s property whose value depends on a property value of its data context?
Sure, VSM and StoryBoard’s are great for animation, but they don’t directly interact with the object’s data context, do they?
Consider the following scenario for discussion:
The border of a Canvas Path should change color and thickness based on the value of an IsSelected property of the Canvas’ data context. Left clicking on the Canvas Path’s enclosed region should toggle the IsSelected property, which should also change the Path’s animation and ultimately color and thickness.
Approach 1
Perhaps I can hook onto the interaction event (i.e. MouseLeftButtonUp) and update the IsSelected property value in the code behind and start a StoryBoard or change the VisualState to animate the Canvas Path. While this may be fine from the animation’s perspective, it strongly couples the view to its view model / data context unless I cast the data context to some IIsSelectable interface.
Approach 2
Perhaps I can create a Behavior that toggles the IISelectable (mentioned above) property and starts the StoryBoard or changes the VisualState. As the Canvas is a Control, it would probably be better to use the VSM rather than just StoryBoard’s (else I would have to somehow pass a reference to the StoryBoard to the Behavior, maybe?).
Approach 3
Perhaps I can use two-way binding with a dual converter so that the initial animation of Canvas Path is determined by the IsSelected property value, but user interactions will change the animation / VisualState which will then update the IsSelected property value. If this is the case, would I convert the Canvas Path’s border color/thickness property or is there a way to properly convert the VisualState (to and from the IsSelected’s boolean value)?
These are just a few ideas off the top of my head. Any other suggestions that would be better practices?
Q1: EventTrigger and System.Windows.TriggerAction is discouraged. The link you give for “they appear to be so useful?” is for System.Windows.Interactivity.TriggerAction whose use is encouraged because it is supported in Blend SL projects and it can be used for more than just the Loaded event.
Q2: You can databind an animation’s To value, but I’d consider creating a custom templated control instead. This way you could define that changes to the IsSelected property change the control’s VSM states.