Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Mouse.MouseDown Attached Event

Occurs when any mouse button is depressed.

Namespace: System.Windows.Input
Assembly: PresentationCore (in PresentationCore.dll)
XML Namespace:  http://schemas.microsoft.com/winfx/2006/xaml/presentation

See Mouse.AddMouseDownHandler, Mouse.RemoveMouseDownHandler
See Mouse.AddMouseDownHandler, Mouse.RemoveMouseDownHandler
See Mouse.AddMouseDownHandler, Mouse.RemoveMouseDownHandler
<object Mouse.MouseDown="MouseButtonEventHandler" .../>

Identifier field

MouseDownEvent

Routing strategy

Bubbling

Delegate

MouseButtonEventHandler

To determine which mouse button was depressed, check the ChangedButton property in the MouseButtonEventArgs passed to the handler.

This is an attached event that is intended through attached event syntax to be referenced by existing user interface (UI) elements that take input.

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 three-button mice, there is no framework-level event support for the center button, and you should use the MouseDown event and check the MiddleButton state in the event arguments.

NoteImportant:

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 section 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?

Windows 98, Windows Server 2000 SP4, Windows CE, Windows Millennium Edition, Windows Mobile for Pocket PC, Windows Mobile for Smartphone, Windows Server 2003, Windows XP Media Center Edition, Windows XP Professional x64 Edition, Windows XP SP2, Windows XP Starter Edition

The Microsoft .NET Framework 3.0 is supported on Windows Vista, Microsoft Windows XP SP2, and Windows Server 2003 SP1.

Community Additions

Show:
© 2014 Microsoft. All rights reserved.