Este artículo se tradujo automáticamente. Para ver el artículo en inglés, active la casilla Inglés. Además, puede mostrar el texto en inglés en una ventana emergente si mueve el puntero del mouse sobre el texto.
Traducción
Inglés

Mouse.MouseDown Evento adjunto

 

Publicado: octubre de 2016

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

Espacio de nombres:   System.Windows.Input
Ensamblado:  PresentationCore (en PresentationCore.dll)

See AddMouseDownHandler, RemoveMouseDownHandler

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

Se trata de un evento adjunto. WPF implementa los eventos adjuntos como eventos enrutados. Eventos asociados son fundamentalmente un XAML el concepto de lenguaje para hacer referencia a los eventos que pueden controlarse en los objetos que no definen ese evento, que WPF expande habilitar también el evento recorrer una ruta. Eventos adjuntos no tienen una sintaxis de control directa en el código. Para adjuntar controladores para un evento enrutado en el código, utilice un complemento designado * método de controlador. Para obtener más información, consulte Attached Events Overview.

El Windows Presentation Foundation (WPF) framework se basa en este evento asociado, y lo expone como dos diferentes Common Language Runtime (CLR) eventos en UIElement y ContentElement: MouseLeftButtonDown y MouseRightButtonDown. Estas implementaciones controlan subyacente MouseDown eventos y leer los argumentos del evento para determinar si participó el botón izquierdo o derecho del mouse. Para un mouse de tres botones, no hay ninguna compatibilidad de eventos de nivel de marco de trabajo para el botón central. Debe utilizar el MouseDown evento y compruebe el MiddleButton argumentos de eventos de estado.

System_CAPS_importantImportante

Unos ContentElement las clases derivadas que tienen comportamiento de control como, por ejemplo, Hyperlink, podrían tener clases inherente de control de eventos de botón del mouse. El botón primario del mouse hacia abajo el evento es el evento más probable que la clase en un control. El control de clases suele marca subyacente Mouse eventos de clase como controlado. Una vez que el evento está marcado como controlado, no se generan normalmente otros controladores de instancia asociados a ese elemento. Cualquier otro controlador instancia o clase que se adjunta a los elementos de la dirección de propagación hacia la raíz en el árbol de la interfaz de usuario también normalmente no se genera.

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

  • Asociar controladores a la PreviewMouseDown evento, que no está marcado como controlado por los controles. Observe que se trata de un evento de vista previa, la ruta comienza en la raíz y desciende hasta el control.

  • Registrar un controlador en el control mediante procedimientos llamando a AddHandler y eligiendo la opción de firma que habilita los controladores para que escuchen los eventos aunque estén marcados como controlados en los datos de eventos enrutados.

Para los eventos enrutados relacionados con el mouse, tenga cuidado sobre cómo y cuándo los marca como controlados. La dificultad de tomar decisiones adecuadas sobre si los elementos primarios deberían también informar sobre cualquier acción del mouse es en realidad por qué la WPF framework eligió el modelo de tener el evento enrutado del mouse subyacente como CLR eventos a lo largo de la ruta. Existen problemas similares con túnel eventos del mouse. ¿Debe controlar el evento y no hacer que lo controlen más elementos secundarios hacia el origen y cómo dicha composición afectan a un control donde las partes integrantes ha esperado comportamientos del mouse?

Campo identificador

MouseDownEvent

Estrategia de enrutamiento

Propagación

delegate

MouseButtonEventHandler

Volver al principio
Mostrar: