Tuve el mismo problema y he encontrado una solución. Encontré esta pregunta después de que la resolví y veo que mi solución tiene mucho en común con la de Mark. Sin embargo, este enfoque es un poco diferente.
El problema principal es que los comportamientos y desencadenantes se asocian con un objeto específico y, por lo tanto, no puede usar la misma instancia de comportamiento para múltiples objetos asociados diferentes. Cuando define su comportamiento en línea, XAML impone esta relación de uno a uno. Sin embargo, cuando intenta establecer un comportamiento en un estilo, el estilo puede reutilizarse para todos los objetos a los que se aplica y esto arrojará excepciones en las clases de comportamiento base. De hecho, los autores hicieron un esfuerzo considerable para evitar que intentáramos hacer esto, sabiendo que no funcionaría.
El primer problema es que ni siquiera podemos construir un valor de establecimiento de comportamiento porque el constructor es interno. Entonces necesitamos nuestro propio comportamiento y activar las clases de recolección.
El siguiente problema es que el comportamiento y las propiedades adjuntas de desencadenador no tienen definidores y, por lo tanto, solo se pueden agregar con XAML en línea. Este problema lo resolvemos con nuestras propias propiedades adjuntas que manipulan el comportamiento primario y las propiedades de activación.
El tercer problema es que nuestra recopilación de comportamiento solo es buena para un solo objetivo de estilo. Esto lo resolvemos mediante la utilización de una característica XAML poco utilizada x:Shared="False" que crea una nueva copia del recurso cada vez que se hace referencia a ella.
El problema final es que los comportamientos y desencadenantes no son como otros establecedores de estilo; no queremos reemplazar los viejos comportamientos con los nuevos comportamientos porque podrían hacer cosas completamente diferentes. Entonces, si aceptamos que una vez que agrega un comportamiento que no puede quitar (y esa es la forma en que los comportamientos funcionan actualmente), podemos concluir que los comportamientos y desencadenantes deben ser aditivos y esto puede ser manejado por nuestras propiedades adjuntas.
Aquí está un ejemplo que utiliza este enfoque:
<Grid>
<Grid.Resources>
<sys:String x:Key="stringResource1">stringResource1</sys:String>
<local:Triggers x:Key="debugTriggers" x:Shared="False">
<i:EventTrigger EventName="MouseLeftButtonDown">
<local:DebugAction Message="DataContext: {0}" MessageParameter="{Binding}"/>
<local:DebugAction Message="ElementName: {0}" MessageParameter="{Binding Text, ElementName=textBlock2}"/>
<local:DebugAction Message="Mentor: {0}" MessageParameter="{Binding Text, RelativeSource={RelativeSource AncestorType={x:Type FrameworkElement}}}"/>
</i:EventTrigger>
</local:Triggers>
<Style x:Key="debugBehavior" TargetType="FrameworkElement">
<Setter Property="local:SupplementaryInteraction.Triggers" Value="{StaticResource debugTriggers}"/>
</Style>
</Grid.Resources>
<StackPanel DataContext="{StaticResource stringResource1}">
<TextBlock Name="textBlock1" Text="textBlock1" Style="{StaticResource debugBehavior}"/>
<TextBlock Name="textBlock2" Text="textBlock2" Style="{StaticResource debugBehavior}"/>
<TextBlock Name="textBlock3" Text="textBlock3" Style="{StaticResource debugBehavior}"/>
</StackPanel>
</Grid>
El ejemplo utiliza disparadores pero los comportamientos funcionan de la misma manera.En el ejemplo, se muestra:
- el estilo se puede aplicar a varios bloques de texto
- varios tipos de encuadernación todo el trabajo correctamente
- una acción de depuración que genera el texto en la ventana de salida de datos
Aquí hay un comportamiento de ejemplo, nuestro DebugAction. Más correctamente es una acción, pero a través del abuso del lenguaje llamamos comportamientos, desencadenantes y acciones "comportamientos".
public class DebugAction : TriggerAction<DependencyObject>
{
public string Message
{
get { return (string)GetValue(MessageProperty); }
set { SetValue(MessageProperty, value); }
}
public static readonly DependencyProperty MessageProperty =
DependencyProperty.Register("Message", typeof(string), typeof(DebugAction), new UIPropertyMetadata(""));
public object MessageParameter
{
get { return (object)GetValue(MessageParameterProperty); }
set { SetValue(MessageParameterProperty, value); }
}
public static readonly DependencyProperty MessageParameterProperty =
DependencyProperty.Register("MessageParameter", typeof(object), typeof(DebugAction), new UIPropertyMetadata(null));
protected override void Invoke(object parameter)
{
Debug.WriteLine(Message, MessageParameter, AssociatedObject, parameter);
}
}
Finalmente, nuestras colecciones y propiedades adjuntas para que todo esto funcione. Por analogía con Interaction.Behaviors, la propiedad a la que se dirige se llama SupplementaryInteraction.Behaviors porque al establecer esta propiedad, agregará comportamientos a Interaction.Behaviors y lo mismo ocurrirá con los desencadenadores.
public class Behaviors : List<Behavior>
{
}
public class Triggers : List<TriggerBase>
{
}
public static class SupplementaryInteraction
{
public static Behaviors GetBehaviors(DependencyObject obj)
{
return (Behaviors)obj.GetValue(BehaviorsProperty);
}
public static void SetBehaviors(DependencyObject obj, Behaviors value)
{
obj.SetValue(BehaviorsProperty, value);
}
public static readonly DependencyProperty BehaviorsProperty =
DependencyProperty.RegisterAttached("Behaviors", typeof(Behaviors), typeof(SupplementaryInteraction), new UIPropertyMetadata(null, OnPropertyBehaviorsChanged));
private static void OnPropertyBehaviorsChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
var behaviors = Interaction.GetBehaviors(d);
foreach (var behavior in e.NewValue as Behaviors) behaviors.Add(behavior);
}
public static Triggers GetTriggers(DependencyObject obj)
{
return (Triggers)obj.GetValue(TriggersProperty);
}
public static void SetTriggers(DependencyObject obj, Triggers value)
{
obj.SetValue(TriggersProperty, value);
}
public static readonly DependencyProperty TriggersProperty =
DependencyProperty.RegisterAttached("Triggers", typeof(Triggers), typeof(SupplementaryInteraction), new UIPropertyMetadata(null, OnPropertyTriggersChanged));
private static void OnPropertyTriggersChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
var triggers = Interaction.GetTriggers(d);
foreach (var trigger in e.NewValue as Triggers) triggers.Add(trigger);
}
}
y ahí lo tiene, los comportamientos totalmente funcionales y los factores desencadenantes aplicados a través de los estilos.
Grandes cosas, esto funciona muy bien. Me di cuenta de que si coloca el estilo, por ejemplo, en los recursos de UserControl, e.NewValue puede ser nulo al principio (puede depender del control utilizado; estoy usando esto en XamDataTreeNodeControl en Infragistics XamDataTree). Así que agregué un pequeño control de cordura en OnPropertyTriggersChanged: if (e.NewValue! = Null) – MetalMikester
¿Alguien ha tenido un problema con este enfoque al aplicar el Setter en un ** Estilo ** implícito? He conseguido que funcione bien con un estilo no implícito (uno con una clave), pero obtengo una excepción de referencia cíclica si está en un estilo implícito. –
Buena solución, pero desafortunadamente no funciona en WinRT, porque x: Shared no existe en esta plataforma ... –