Mouse.MouseDown Attached Event
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Occurs when any mouse button is depressed.
see AddMouseDownHandler, and RemoveMouseDownHandlersee AddMouseDownHandler, and RemoveMouseDownHandlersee AddMouseDownHandler, and RemoveMouseDownHandlerRemarks
To determine which mouse button was depressed, check the ChangedButton property in the MouseButtonEventArgs passed to the handler.
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 and ContentElement: MouseLeftButtonDown and MouseRightButtonDown. These implementations handle the underlying MouseDown event and read the arguments of the event to determine whether the left or right mouse button was involved. For a three-button mouse, there is no framework-level event support for the center button. You should use the MouseDown event and check the MiddleButton state in the event arguments.
Important
A few ContentElement derived classes that have control-like behavior, for example, Hyperlink, might have inherent class handling for mouse button events. The left mouse button down event is the most likely event to have class handling in a control. The class handling often marks the underlying Mouse class event as handled. Once the event is marked handled, other instance handlers that are attached to that element are not ordinarily raised. Any other class or instance handlers that are attached to elements in the bubbling direction towards the root in the UI tree are also not ordinarily raised.
You can resolve the issue that is outlined in the preceding Important note and still receive MouseDown events for left mouse button down events on a derived class that has class handling by using either of these solutions:
Attach handlers for the PreviewMouseDown event, which is not marked as handled by the controls. Notice that because this is a preview event, the route starts at the root and tunnels down to the control.
Register a handler on the control procedurally by calling AddHandler and choosing the signature option that enables handlers to listen for events even if they are already marked as handled in the routed event data.
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 along the route. Similar issues exist with tunneling mouse events. Should you handle the event and not have it be handled by further children toward the source, and how would that affect compositing a control where the compositing pieces might have expected mouse behaviors?
Routed Event Information
| Identifier field | MouseDownEvent |
| Routing strategy | Bubbling |
| Delegate | MouseButtonEventHandler |
- The corresponding tunneling event is PreviewMouseDown.
