First off a disclaimer. Just because you can do this doesn’t mean you should :)

<x:Code>
   <![CDATA[
   private void OKButton_Click(object sender, RoutedEventArgs e)
   {
      MessageBox.Show("OK Clicked");
   }
   ]]>            
</x:Code>

<Button Content="OK" Width="80" Margin="3" Click="OKButton_Click" />

There’s not a lot to say about this one except that it’s possible to embed code in XAML. Obviously it’s easier to code it, generally speaking, in the code behind and better still in the view model. But the option is there :)

This is nothing new. I know of several MVVM frameworks that do this, but this was my take on a solution for the following:

So you have events on a UIElement, for example a Button has MouseEnter and MouseLeave (amongst others). By default the events require an event handler which would might be placed in the “code behind” in the view itself. But this is no use if, for example a MouseEnter should update some data from the view model unless you want to do more coding in the view to access the view model and makes calls directly on it, which is a somewhat against the spirit of MVVM. So what would be cool is if the MouseEnter could instead be bound to a view model command instead.

Being that part of the mechanism already exists in EventTriggers then we just need to supply a trigger action to bind to the view model.

For example the XAML might look like:

<Button Content="Cancel" Width="80" Margin="3" >
   <i:Interaction.Triggers>
      <i:EventTrigger EventName="MouseEnter">
         <controls:CommandAction Command="{Binding ClearSearch}" />
      </i:EventTrigger>
   </i:Interaction.Triggers>
</Button>

The code for the TriggerAction is simple

public class CommandAction : TriggerAction<DependencyObject>
{
   public static readonly DependencyProperty CommandProperty =
	DependencyProperty.Register("Command", typeof(ICommand), typeof(CommandAction),
	new PropertyMetadata(null, OnCommandChanged));

   public static readonly DependencyProperty CommandParameterProperty =
	DependencyProperty.Register("CommandParameter", typeof(object), typeof(CommandAction),
	new PropertyMetadata(null, OnCommandParameterChanged));

   private IDisposable canExecuteChanged;

   public ICommand Command
   {
      get { return (ICommand)GetValue(CommandProperty); }
      set { SetValue(CommandProperty, value); }
   }

   public object CommandParameter
   {
      get { return GetValue(CommandParameterProperty); }
      set { SetValue(CommandParameterProperty, value); }
   }

   private static void OnCommandChanged(DependencyObject sender, 
                   DependencyPropertyChangedEventArgs e)
   {
      CommandAction ev = sender as CommandAction;
      if(ev != null)
      {
         if (ev.canExecuteChanged != null)
	 {
	    ev.canExecuteChanged.Dispose();
	 }

	 ICommand command = e.NewValue as ICommand;
	 if (command != null)
	 {
	    ev.canExecuteChanged = Observable.FromEventPattern(
			x => command.CanExecuteChanged += x,
			x => command.CanExecuteChanged -= x).Subscribe
			(_ => ev.SynchronizeElementState());
	 }
      }
   }

   private static void OnCommandParameterChanged(DependencyObject sender,
            DependencyPropertyChangedEventArgs e)
   {
      CommandAction ev = sender as CommandAction;
      if (ev != null)
      {
         ev.SynchronizeElementState();
      }
   }

   private void SynchronizeElementState()
   {
      ICommand command = Command;
      if (command != null)
      {
         FrameworkElement associatedObject = AssociatedObject as FrameworkElement;
	 if (associatedObject != null)
	 {
	    associatedObject.IsEnabled = command.CanExecute(CommandParameter);
	 }
      }	
   }

   protected override void Invoke(object parameter)
   {
      ICommand command = Command;
      if(command != null)
      {
         command.Execute(CommandParameter);
      }
   }
}

We derive our class from TriggerAction and declare any dependency properties etc. we want on it. So if you ignore all the setting up of Command & CommandParameter code, this really boils down to the override of the Invoke method. This is what’s called when the trigger condition is met.

A quick post about blend behaviors in WPF. A behavior (from the System.Windows.Interactive assembly) allows us to add functionality to elements within the UI tree. An example might better serve to describe what one is and how to write one.

Let’s make things simple and say we have a UI element which we want to fade into the background when not focus. So we can create a class derived from Behavior<>. Looking at the properties on a UIElement this will suffice for our needs so we’ll derive our FadeOnLostFocusBehavior (bit of a mouthful) from Behavior.

If we jump straight to the code we get something like

public class FadeOnLoseFocusBehavior : Behavior<UIElement>
{
   private const float FADED = 0.2f;

   protected override void OnAttached()
   {
      AssociatedObject.LostFocus += AssociatedObject_LostFocus;
      AssociatedObject.GotFocus += AssociatedObject_GotFocus;

      // this just ensures a default state of faded for the control
      AssociatedObject.Opacity = FADED;

      base.OnAttached();
   }

   protected override void OnDetaching()
   {
      AssociatedObject.LostFocus -= AssociatedObject_LostFocus;
      AssociatedObject.GotFocus -= AssociatedObject_GotFocus;

      base.OnDetaching();
   }

   private void AssociatedObject_LostFocus(object sender, RoutedEventArgs e)
   {
      AssociatedObject.Opacity = FADED;
   }	

   private void AssociatedObject_GotFocus(object sender, RoutedEventArgs e)
   {
      AssociatedObject.Opacity = 1;
   }
}

The above is very simple. When we attach the behavior to the UIElement we connect to the required events on the AssociatedObject. When we detach from the UIElement we detach from the events on the AssociatedObject. The rest is self-explanatory.

The XAML for this example would look like

<Button Content="Cancel" Width="80" Margin="3" >
   <i:Interaction.Behaviors>
      <controls:FadeOnLoseFocusBehavior />
   </i:Interaction.Behaviors>
</Button>