Mouse.MouseDown Evento adjunto

  • Referencia

Definición

Espacio de nombres:
System.Windows.Input
Ensamblado:
PresentationCore.dll

Se produce cuando se presiona cualquier botón del mouse.

see AddMouseDownHandler, and RemoveMouseDownHandler
see AddMouseDownHandler, and RemoveMouseDownHandler
see AddMouseDownHandler, and RemoveMouseDownHandler

Comentarios

Para determinar qué botón del mouse se deprimió, compruebe la ChangedButton propiedad en el MouseButtonEventArgs controlador pasado.

Se trata de un evento adjunto. WPF implementa eventos adjuntos como eventos enrutados. Los eventos adjuntos son fundamentalmente un concepto de lenguaje XAML para hacer referencia a eventos que se pueden controlar en objetos que no definen ese evento, que WPF se expande también al permitir que el evento recorra una ruta. Los eventos adjuntos no tienen una sintaxis de control directo en el código; para adjuntar controladores para un evento enrutado en el código, se usa un método Add*Handler designado. Para obtener más información, consulte Información general sobre eventos adjuntos.

El marco de trabajo de Windows Presentation Foundation (WPF) se basa en este evento adjunto al exponerlo como dos eventos de Common Language Runtime (CLR) diferentes en UIElement y : MouseLeftButtonDown y ContentElementMouseRightButtonDown. Estas implementaciones controlan el evento subyacente MouseDown y leen los argumentos del evento para determinar si el botón izquierdo o derecho del mouse estaba implicado. Para un mouse de tres botones, no hay compatibilidad con eventos de nivel de marco para el botón central. Debe usar el MouseDown evento y comprobar el MiddleButton estado en los argumentos del evento.

Importante

Algunas ContentElement clases derivadas que tienen un comportamiento similar al control, por ejemplo, Hyperlink, pueden tener un control de clases inherente para eventos de botón del mouse. El evento de botón izquierdo del mouse hacia abajo es el evento más probable que tenga control de clases en un control. El control de clases suele marcar el evento de clase subyacente Mouse como controlado. Una vez que el evento está marcado como controlado, otros controladores de instancia que están asociados a ese elemento no se generan normalmente. Cualquier otro controlador de clase o instancia que esté asociado a elementos en la dirección de propagación hacia la raíz en el árbol de la interfaz de usuario tampoco se eleva normalmente.

Puede resolver el problema que se describe en la nota importante anterior y seguir recibiendo MouseDown eventos para los eventos de botón izquierdo del mouse hacia abajo en una clase derivada que tiene control de clases mediante cualquiera de estas soluciones:

  • Adjunte controladores para el PreviewMouseDown evento, que no está marcado como controlado por los controles. Tenga en cuenta que, dado que se trata de un evento de vista previa, la ruta comienza en la raíz y los túneles hacia abajo hasta el control.

  • Registre un controlador en el control mediante una llamada AddHandler a y elija la opción de firma que permite a los controladores escuchar eventos incluso si ya están marcados como controlados en los datos de eventos enrutados.

Para los eventos enrutados relacionados con el mouse, tenga cuidado sobre cómo o al marcarlos controlados. La dificultad para tomar las decisiones adecuadas sobre si los elementos primarios también deben informarse sobre cualquier acción del mouse determinada es, de hecho, por qué el marco de WPF eligió el modelo de tener el evento enrutado del mouse subyacente que se muestra como eventos CLR a lo largo de la ruta. Existen problemas similares con los eventos del mouse de tunelización. ¿Debe controlar el evento y no tenerlo controlado por elementos secundarios adicionales hacia el origen y cómo afectaría a la composición de un control en el que las piezas de composición podrían tener comportamientos esperados del mouse?

Información sobre eventos enrutados
Campo identificador MouseDownEvent
Estrategia de enrutamiento Burbujeante
Delegado MouseButtonEventHandler

Se aplica a