Mouse.MouseDown Evento Anexado
Definição
Importante
Algumas informações dizem respeito a um produto pré-lançado que pode ser substancialmente modificado antes de ser lançado. A Microsoft não faz garantias, de forma expressa ou implícita, em relação à informação aqui apresentada.
Ocorre quando qualquer botão do rato é pressionado.
see AddMouseDownHandler, and RemoveMouseDownHandlersee AddMouseDownHandler, and RemoveMouseDownHandlersee AddMouseDownHandler, and RemoveMouseDownHandlerObservações
Para determinar qual botão do rato foi pressionado, verifique a ChangedButton propriedade no MouseButtonEventArgs passado para o handler.
Este é um evento anexado. O WPF implementa eventos anexos como eventos encaminhados. Os eventos anexados são fundamentalmente um conceito de linguagem XAML para referenciar eventos que podem ser tratados em objetos que não definem esse evento, o que o WPF expande ao permitir também que o evento percorra uma rota. Os eventos anexados não têm uma sintaxe de tratamento direta no código; para anexar handlers para um evento encaminhado no código, utiliza-se um método designado Add*Handler. Para mais detalhes, consulte a Visão Geral dos Eventos em Anexo.
A framework Windows Presentation Foundation (WPF) baseia-se neste evento anexo, apresentando-o como dois eventos diferentes de runtime de linguagem comum (CLR) em UIElement e ContentElement: MouseLeftButtonDown e MouseRightButtonDown. Estas implementações lidam com o evento subjacente MouseDown e leem os argumentos do evento para determinar se o botão esquerdo ou direito do rato estava envolvido. Para um rato de três botões, não existe suporte para eventos ao nível da framework para o botão central. Deves usar o MouseDown evento e verificar o MiddleButton estado nos argumentos do evento.
Importante
Algumas ContentElement classes derivadas que têm comportamento semelhante ao controlo, por exemplo, Hyperlink, podem ter tratamento inerente de classes para eventos de botão do rato. O evento do botão esquerdo do rato é o evento mais provável de ter manipulação de classes num controlo. A gestão de classes frequentemente marca o evento subjacente Mouse da classe como tratado. Uma vez marcado o evento como tratado, outros handlers de instância que estão ligados a esse elemento normalmente não são levantados. Qualquer outro handler de classe ou instância que esteja associado a elementos na direção de borbulhar em direção à raiz na árvore UI também não são normalmente elevados.
Pode resolver o problema descrito na nota importante anterior e ainda assim receber MouseDown eventos para o botão esquerdo do rato numa classe derivada que tenha gestão de classes usando qualquer uma destas soluções:
Anexe os handlers para o PreviewMouseDown evento, que não está marcado como tratado pelos controlos. Repare que, por ser um evento de pré-visualização, a rota começa na raiz e desce até ao controlo.
Registe um handler no controlo proceduralmente, chamando AddHandler e escolhendo a opção de assinatura que permite aos handlers ouvir eventos mesmo que já estejam marcados como tratados nos dados do evento encaminhado.
Para eventos encaminhados relacionados com o rato, tenha cuidado com a forma ou quando os marca como tratados. A dificuldade em fazer as escolhas apropriadas sobre se os elementos pais devem também ser informados sobre qualquer ação do rato é, de facto, a razão pela qual o framework WPF escolheu o modelo de fazer com que o evento encaminhado subjacente do rato seja apresentado como eventos CLR ao longo da rota. Problemas semelhantes existem com eventos de rato por tunelamento. Deves tratar do evento e não deixá-lo ser tratado por crianças mais próximas da fonte, e como é que isso afetaria a composição de um controlo onde as partes de composição poderiam ter esperado comportamentos de rato?
Informação sobre Eventos Roteados
| Número | valor |
|---|---|
| Campo identificador | MouseDownEvent |
| Estratégia de encaminhamento | Borbulhar |
| Delegado | MouseButtonEventHandler |
- O evento correspondente de tunelamento é PreviewMouseDown.