Mouse.MouseUp Evento adjunto
Definición
Importante
Parte de la información hace referencia a la versión preliminar del producto, que puede haberse modificado sustancialmente antes de lanzar la versión definitiva. Microsoft no otorga ninguna garantía, explícita o implícita, con respecto a la información proporcionada aquí.
Se produce cuando se suelta cualquier botón del mouse.
see AddMouseUpHandler, and RemoveMouseUpHandlersee AddMouseUpHandler, and RemoveMouseUpHandlersee AddMouseUpHandler, and RemoveMouseUpHandlerComentarios
El botón del mouse que se liberó se determina comprobando los argumentos del evento.
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 Windows Presentation Foundation (WPF) se basa en este evento adjunto al exponerlo como dos eventos de Common Language Runtime (CLR) diferentes en UIElement: MouseLeftButtonUp y MouseRightButtonUp. Estas implementaciones controlan el evento subyacente MouseUp y leen los argumentos del evento para determinar si el botón izquierdo o derecho del mouse estaba implicado. Para tres botones, no hay compatibilidad con eventos de nivel de marco para el botón central y debe usar el evento y comprobar la MouseUp condición del botón central en los argumentos del evento.
Para los eventos enrutados relacionados con el mouse, tenga cuidado sobre cómo o al marcarlos controlados. La dificultad para tomar las opciones adecuadas sobre si los elementos primarios también deben informarse sobre cualquier acción del mouse determinada es, de hecho, por qué el marco wpF eligió el modelo de tener el evento enrutado subyacente Mouse que se muestra como eventos CLR en toda la ruta.
Existen problemas similares con los eventos del mouse de tunelización. ¿Debe controlar el evento y no controlarlo los elementos secundarios hacia el origen y cómo afectaría a la composición en un control en el que las partes de composición podrían tener comportamientos esperados del mouse?
Información sobre eventos enrutados
| Campo identificador | MouseUpEvent |
| Estrategia de enrutamiento | Burbujeante |
| Delegado | MouseButtonEventHandler |
El evento de tunelización correspondiente es PreviewMouseUp.
