]]>https://vspivak.wordpress.com/2012/03/04/sometimes-i-am-going-mad-mad-mad/feed/0vspivakProblem with Microsoft.Expression.Interactivity.Core.DataTriggerhttps://vspivak.wordpress.com/2011/04/12/problem-with-microsoft-expression-interactivity-core-datatrigger/
https://vspivak.wordpress.com/2011/04/12/problem-with-microsoft-expression-interactivity-core-datatrigger/#respondTue, 12 Apr 2011 18:07:07 +0000http://vspivak.wordpress.com/?p=79It looks like DataTrigger have some annoying bug – it does not respect FrameworkElement loading sequence and this way misses those bindings that are, for example, resource bound.

]]>https://vspivak.wordpress.com/2011/04/12/problem-with-microsoft-expression-interactivity-core-datatrigger/feed/0vspivakUsing System.Windows.Interactivity Behaviors and Actions in WPF/Silverlight styleshttps://vspivak.wordpress.com/2011/01/19/using-system-windows-interactivity-behaviors-and-actions-in-wpfsilverlight-styles/
https://vspivak.wordpress.com/2011/01/19/using-system-windows-interactivity-behaviors-and-actions-in-wpfsilverlight-styles/#commentsWed, 19 Jan 2011 23:36:36 +0000http://vspivak.wordpress.com/?p=53You may somehow disagree, but System.Windows.Interactivity is good approach not only in Blend, but also in frontal WPF/Silverlight development. Recently I finally and completely stopped to use ICommandSource directly (I mean <Button Command=”<blabla>”/>) and instead I am using Interactivity.EventTrigger on “Click” event with appropriate action. But Interactivity facilities have some caveat preventing convenient use from Style setters – both Triggers and Behaviors are read-only properties. So, I can’t write some xaml like this:

Ok, but I really want this working! So lets find a solution that works in both WPF and Silverlight. At a first glance the solution seemed simple: fill some lists on your defined object, use some attached property and in it’s OnPropertyChange notifier copy your interaction elements into actual Interactivity lists:

As you can understand from the comment, such approach is not working as expected. There are two reasons for that. The first reason is that our definition is Style-wide, so we actually adding the same instances of Actions and Behaviors to all instances of elements this style will be applied to. Obviously, this is not supported – each Behaviour or Trigger instance may have only one AssociatedObject. The second issue, that Triggers and Behaviors usually are Binding-rich and those bindings will be evaluated at the moment when style will be instantiated instead of the moment when style will be actually applied to element.
Fortunately, there is built-it mechanism in both WPF and Silverlight that supports later evaluation of object tree including all markup definitions such as bindings, resource accessors or such – FrameworkTemplate.
There are 3 built-in subclasses of FrameworkTemplate – DataTemplate, ControlTemplate and ItemPanelTemplate. In current version of WPF we can not subclass FrameworkTemplate directly due to existence of some abstract internal member. But instead we can subclass DataTemplate. So working solution will look like the follows: