ICommand for Silverlight with Attached Behaviors

Silverlight has many things in common with WPF, but also many different or missing things because it is a “subset” of it.

One of the missing things is support for the ICommand interface (UPDATE: in Silverlight 2, this interface was included, but there is no implementation that uses it, so this post is still useful and the sample was updated to use Silverlight’s interface instead of my own copy of it from WPF). I find this interface (and the button’s behavior when bound to a command) extremely useful/necessary, especially when using DataTemplates bound to a Presentation Model (to provide the view for the model), as hooking events (like Click) is not an option in this scenario.

<Button Content="Save" Command="{Binding SaveOrderCommand}" />

As you might suspect, we (at p&p) are now spiking and seeing how the Composite Application Library for WPF (a.k.a. Prism or CompositeWPF) would work on Silverlight. One important part of the guidance provided is to use Commands for communication between the moving parts, and from the view (this is specially useful for testability).

Today the team published a small drop that contains some of the spikes we’ve been playing with, including an initial quick & dirt port of the library. We added the ICommand interface that is missing from WPF to the same System.Windows.Input namespace, not only to avoid adding new using statements all throughout the solutions, but in my opinion, because we hope Silverlight might support this out-of-the-box in the future, and we might be able to quickly switch to the provided implementation easily if they stay consistent with WPF’s API. (UPDATE: the interface is now part of Silverlight 2)

namespace System.Windows.Input
    public interface ICommand
        bool CanExecute(object parameter);
        void Execute(object parameter);
        event EventHandler CanExecuteChanged;

Once the ICommand interface is there, the DelegateCommand and CompositeCommand implementations included in CompositeWPF start working immediately and I can now call command.Execute(null) on my commands… big deal! But I want to hook my buttons to those commands from XAML!

public class DelegateCommand<T> : ICommand { ... }

Well, how to hook to a command using XAML? easy: using attached behaviors. First, I need to define an attached property that will contain the command.

public static readonly DependencyProperty CommandProperty =
    DependencyProperty.RegisterAttached("Command", typeof(ICommand), typeof(Commands),
    new PropertyMetadata(CommandPropertyChanged));

Ok, I can attach the command to a button, but how will it be invoked when the button is clicked? Well, that’s when CommandPropertyChanged kicks in (and that’s why it’s an attached behavior, and not just a simple attached property):

private static void CommandPropertyChanged(DependencyObject o, DependencyPropertyChangedEventArgs e)
    ButtonBase element = o as ButtonBase;
    if (element != null)
        if (e.OldValue != null)
            CommandButtonBehavior behavior = (CommandButtonBehavior)element.GetValue(CommandButtonBehaviorProperty);
            element.SetValue(CommandButtonBehaviorProperty, behavior);
        if (e.NewValue != null)
            CommandButtonBehavior behavior = new CommandButtonBehavior(element, (ICommand)e.NewValue));

The code above creates an instance of a behavior class that contains the behavior. This instance is stored in a private attached property, in order to be able to retrieve the behavior and Detach it when unhooking the command (when e.OldValue is not null).

The following code shows how CommandButtonBehavior hooks to the Click event of the Button in order to invoke the command.

private class CommandButtonBehavior
    private readonly WeakReference elementReference;
    private readonly ICommand command;

    public CommandButtonBehavior(ButtonBase element, ICommand command)
        this.elementReference = new WeakReference(element);
        this.command = command;

    public void Attach()
        ButtonBase element = GetElement();
        if (element != null)
            element.Click += element_Clicked;

    public void Detach()
        ButtonBase element = GetElement();
        if (element != null)
            element.Click -= element_Clicked;

    private static void element_Clicked(object sender, EventArgs e)
        DependencyObject element = (DependencyObject)sender;
        ICommand command = (ICommand)element.GetValue(CommandProperty);
        object commandParameter = element.GetValue(CommandParameterProperty);

    private ButtonBase GetElement()
        return elementReference.Target as ButtonBase;

The reason for storing the button as a WeakReference, is to avoid the application from leaking memory when trying to destroy a view with a button that has not correctly unhooked the command.

Ok, I believe that this bunch of code might be helpful, but how to use it from XAML? Again, easy:

<Button Content="Save" Commands:Commands.Command="{Binding Path=SaveOrderCommand}" />

As you can see, this looks way too similar to how WPF commands are declared, except for the Commands:Commands part of it, because this is an attached property and not a direct dependency property of the Button class.

I’m attaching a sample that uses the classes published in Codeplex by the Prism team. The sample includes support for CommandParameter and allows enabling and disabling the button depending on whether the ICommand.CanExecute method returns true or false.


Note: Even if I’m using DelegateCommand, you could use your own implementation of ICommand, as the attached behavior is not coupled to any implementation of ICommand.


This code is provided “AS IS” with no warranties, and confers no rights.


You can get the sample with the attached behaviors from here (updated for SL 2 RTW), or you can download the code for the behaviors without the sample from the latest change set of the CompositeWPF source control, in the spikes folder.

More information

Nikhil Kothari has a great introduction and samples for attached behaviors on Silverlight here.

John Gossman blogs about attached behaviors on WPF (here and here).

Dave Relyea created a neat example of attached behavior on Silverlight here.

Ezequiel Jadib has more info on the spike published in Codeplex here.

Shout it


  • mhenderson says:

    Thanks for this example. This is super helpful.

    How do you handle the situation where we have a control in the usercontrol that has overriden the datacontext, but we still want to bind to the usercontrol’s datacontext?

    I’m specifically talk about a DataGrid in the UserControl where the ItemsSource has been set. We want to have a command fire on an individual row, but cannot bind to the datacontext of the usercontrol because it is out of scope at that point.

    Any ideas?


  • jdominguez says:

    I’m glad you liked the example.
    Regarding the question, in Silverlight you cannot create a Binding with RelativeSource…
    Nevertheless, you could store the command in a Resource, and bind to it from the rows. You may have a problem with the timing there though, because Silverlight does not support DynamicResource either (just StaticResource).
    Let me know if this helps solve the problem.

  • mhenderson says:

    We thought about the resource, but that seems like added XAML overhead in declaring our commands (plus, I agree that there might be a timing issue). We’d like the wireing mechanism to be as terse as possible. Here’s what we ended up with:

    We’re using Presentation Model (M-V-VM) and IView is the root where we’re getting the DataContext containing the ICommands. We need to get the IView parent (or grandparent, great-grandparent, etc) from the ButtonBase. However, due to timing, the parent isn’t set when the Command is set, so we changed the Command attached property to be a string instead of an ICommand and store the value. Next, we subscribe to the ButtonBase loaded event, so that, on load, we walk up the FrameworkElement parent until we get to the IView and get it’s DataContext. Then we use reflection (from the stored command string) to get the appropriate ICommand on the DataContext and wire up the buttonbase click.

    Additionally, we can have tests that ensure all the wiring happens correctly. It seems to work well so far, plus we get to use reflection :)

    Any thoughts?


Leave a Reply