Mouse.MouseUp Attached Event
Occurs when any mouse button is released.
Assembly: PresentationCore (in PresentationCore.dll)
XMLNS for XAML: http://schemas.microsoft.com/winfx/2006/xaml/presentation, http://schemas.microsoft.com/netfx/2007/xaml/presentation
Which mouse button was released is determined by checking the arguments of the event.
This is an attached event. WPF implements attached events as routed events. Attached events are fundamentally a XAML language concept for referencing events that can be handled on objects that do not define that event, which WPF expands upon by also enabling the event to traverse a route. Attached events do not have a direct handling syntax in code; to attach handlers for a routed event in code, you use a designated Add*Handler method. For details, see Attached Events Overview.
The Windows Presentation Foundation (WPF) framework builds on this attached event by surfacing it as two different common language runtime (CLR) events on UIElement: MouseLeftButtonUp and MouseRightButtonUp. These implementations handle the underlying event and read the arguments of the event to determine whether the left or right mouse button was involved. For three-button, there is no framework-level event support for the center button, and you should use the event and check for the center button condition in the event arguments.
For routed events that relate to the mouse, be careful about how or when you mark them handled. The difficulty in making the appropriate choices about whether parent elements should also be informed about any given mouse action is in fact why the WPF framework chose the model of having the underlying Mouse routed event be surfaced as CLR events all along the route.
Similar issues exist with tunneling mouse events. Should you handle the event and not have it be handled by children further towards the source, and how would that affect compositing in a control where the compositing pieces might have expected mouse behaviors?