Mouse Event Commands for MVVM

Matthew Searles

Rate me:

4.95/5 (19 votes)

22 Jan 2013CPOL

111.4K

3.2K

Use an Attached Property to execute an ICommand.

Download source code - 9 KB

Introduction

If you ever want to pass MouseEventArgs to a ViewModel, here's a neat way to do it Smile | <img src=

The Attached Property

public class MouseBehaviour
{
    public static readonly DependencyProperty MouseUpCommandProperty =
        DependencyProperty.RegisterAttached("MouseUpCommand", typeof(ICommand), 
        typeof(MouseBehaviour), new FrameworkPropertyMetadata(
        new PropertyChangedCallback(MouseUpCommandChanged)));

    private static void MouseUpCommandChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        FrameworkElement element = (FrameworkElement)d;

        element.MouseUp += new MouseButtonEventHandler(element_MouseUp);
    }

    static void element_MouseUp(object sender, MouseButtonEventArgs e)
    {
        FrameworkElement element = (FrameworkElement)sender;

        ICommand command = GetMouseUpCommand(element);

        command.Execute(e);
    }

    public static void SetMouseUpCommand(UIElement element, ICommand value)
    {
        element.SetValue(MouseUpCommandProperty, value);
    }

    public static ICommand GetMouseUpCommand(UIElement element)
    {
        return (ICommand) element.GetValue(MouseUpCommandProperty);
    }
}

We simply register the attached property, hook the MouseUp event for the FrameworkElement, and invoke the Command in the handler. Simple enough, right?

Usage

XML

<Image Source="c:/temp.png" [Your xmlns]:MouseBehaviour.MouseUpCommand="{Binding MouseUpCommand}"></Image>

You do not, of course, have to use an <Image>, any framework element will work just fine. That's the beauty of Attached Properties!

Having trouble attaching source, which contains Attached Properties for handling any mouse event MVVM style. But when it's up, includes

MouseUp
MouseDown
MouseEnter
MouseLeave
MouseLeftButtonDown
MouseLeftButtonUp
MouseMove
MouseRightButtonDown
MouseRightButtonUp
MouseWheel

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By

Matthew Searles

Software Developer Lovatts Publications

Australia

This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

Re: My vote of 5

Matt Searles11-Mar-14 15:00

Matt Searles

11-Mar-14 15:00

Thanks Wolfgang, happy coding!

Bubbled events prevent this from working

RickB_AZ1-Jan-14 5:32

RickB_AZ

1-Jan-14 5:32

Great code, but a caveat should be given to beware trying to attach to bubbled events that are marked as handled by the control class. For example,attaching a command to MouseDown will not work for a Button because the event does not bubble up. Attaching to the PreviewMouseDown will work because it is tunneled.

Rick B

Re: Bubbled events prevent this from working

selfwalker27-Mar-14 16:39

selfwalker

27-Mar-14 16:39

Thanks, you helped me a lot

Garbage Collection?

haindl17-Oct-12 21:39

haindl

17-Oct-12 21:39

What about Garbage Collection?
As far as I can see, the FrameworkElement never gets removed from memory because the EventHandler is permanently referencing it.

If (for example) the FrameworkElement is inside a DataTemplate or a ControlTemplate it might be instantiated many many times.
So you may have a problem in the resource management of your application sooner or later because of the memory leakes caused by the strong references.

Maybe you should extend your code to use WeakEvents.
(Good starting point: http://msdn.microsoft.com/en-us/library/aa970850.aspx[^])

Re: Garbage Collection?

Dakko18-Oct-12 0:49

Dakko

18-Oct-12 0:49

FrameworkElement has a reference to MouseBehaviour class but not the other way round. Am I right?

Re: Garbage Collection?

haindl18-Oct-12 1:50

haindl

18-Oct-12 1:50

Hmm...
I profiled the code and it seems that you are right indeed.
Apparently I mixed something up and therefore I withdraw my previous comment.
There's no need for WeakEvents here - I was wrong.

Re: Garbage Collection?

MarkWardell11-May-15 14:38

MarkWardell

11-May-15 14:38

So why wont this cause a a leak I am confused. Doesnt the EventHandler Keep the FrameworkElement from Releasing to the GC?

Re: Garbage Collection?

haindl12-May-15 2:15

haindl

12-May-15 2:15

You may not believe it, but almost 3 years after my last comment I still struggle with this topic.
As a matter of fact I had a similar problem in my current development work about an hour ago and just came to CodeProject to revisit this article again.
And as funny as it may sound - I then saw that you commented shortly before and decided to give it another go.

Back then I ended up using a MemoryProfiler to verify the references.
Now I've made a simple ConsoleApplication to demonstrate the situation.
As you can see I have mocked the essential parts.

For the sake of simplicity I omitted the Attached MouseUpCommand-DependencyProperty.
This doesn't affect any memory references.
(Feel free to try it with a real WPF-FrameworkElement in XAML.)

As you can clearly see if you run the ConsoleApplication:
After the last reference to the FrameworkElement is gone, it will be finalized correctly.
As long as MouseBehaviour doesn't have a field to store the FrameworkElement, there is no permanent reference.

The reason behind this is the fact that an event is backed by a field (residing in FrameworkElement) which stores the (Multicast)Delegate to the method of the subscriber that does the "+=" (MouseBehaviour.MouseUpHappened in my case).
So FrameworkElement has a reference to MouseBehaviour and not the other way around.
When the last reference to the FrameworkElement is deallocated, then the GC will happily finalize it.

If MouseBehaviour would have stored the FrameworkElement in a field then FrameworkElement would not be finalized.
(You can uncomment the _fe = fe line to see the difference.)
So the essence to success is to never store the FrameworkElement inside of MouseBehaviour.

I hope that I haven't overlooked something important.
Please don't hesitate to leave a comment if there is something unclear. Smile | :)

using System;

namespace ReferenceTestConsoleApplication
{
    public class Program
    {
        private static FrameworkElement _fe = null;

        public static void Main(string[] args)
        {
            _fe = new FrameworkElement();
            MouseBehaviour.SubscribeToMouseUp(_fe);

            Console.WriteLine("1st GC started");
            GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, blocking: true);
            GC.WaitForPendingFinalizers();
            Console.WriteLine("1st GC ended\r\n");

            Console.WriteLine("Last reference to FrameworkElement is cleared " +
                "(e.g. if WPF isn't using it anymore)\r\n");
            _fe = null;

            Console.WriteLine("2nd GC started");
            GC.Collect(GC.MaxGeneration, GCCollectionMode.Forced, blocking: true);
            GC.WaitForPendingFinalizers();
            Console.WriteLine("2nd GC ended");

            Console.ReadLine();
        }
    }

    public static class MouseBehaviour
    {
        private static FrameworkElement _fe = null;

        public static void SubscribeToMouseUp(FrameworkElement fe)
        {
            fe.MouseUp += MouseUpHappened;
            Console.WriteLine("MouseBehaviour is now subscribing to " +
                "FrameworkElement.MouseUp\r\n");

            // If you uncomment the following line, FrameworkElement won't be finalized.
            // Or to be precise:
            // It will only be finalized after the above Console.ReadLine().
            //_fe = fe;
        }

        private static void MouseUpHappened()
        {
            Console.WriteLine("MouseUp happened (never called)");
        }
    }

    public class FrameworkElement
    {
        public event Action MouseUp;

        public void FireMouseUp()
        {
            if (MouseUp != null)
                MouseUp();
        }

        ~FrameworkElement()
        {
            Console.WriteLine("FrameworkElement is now finalized.");
        }
    }
}

The output is:

MouseBehaviour is now subscribing to FrameworkElement.MouseUp

1st GC started
1st GC ended

Last reference to FrameworkElement is cleared (e.g. if WPF isn't using it anymore)

2nd GC started
FrameworkElement is now finalized.
2nd GC ended

Edit: Just applied some formatting to the text.

modified 12-May-15 8:34am.

Re: Garbage Collection?

Matt Searles20-Jun-15 14:02

Matt Searles

20-Jun-15 14:02

No more so than if you wrote <Button Click="MyClickHandler"></Button>...

It's no problem to hook an event with a static handler

Eg. element.Click += SomeHandler;

element creates a reference to the handler method so it knows what to call when the event is fired, GC doesn't get involved because its not going to try and collect a static method.

If the handler method lived on an instance of an object, that's a different story

Eg. element.Click += someOtherObject.SomeHandler;

element has to create a reference to someOtherObject so it can call someOtherObject's method when the event is fired

Now, when GC starts asking "Does anyone still reference you?", someOtherObject will say "yes, element references me so it can call my method, don't collect me."

Therefore we need to -= the handler so we can collect someOtherObject.

Eg. element.Click -= someOtherObject.SomeHandler;

In essence, element *depends* on someOtherObject being alive because it *has* to be able to call it's method. someOtherObject wouldn't care at all if element didn't exist anymore, all that means is that it's handler would never be called.

In the case of MouseBehaviours, element is hooking a static method, so, no problem and an instance of MouseBehaviours is not being new'd up, so again, no problem.

modified 20-Jun-15 21:34pm.

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.