Partage via


UIElement.PointerExited Événement

Définition

Se produit lorsqu’un pointeur quitte la zone de test d’accès de cet élément.

public:
 virtual event PointerEventHandler ^ PointerExited;
// Register
event_token PointerExited(PointerEventHandler const& handler) const;

// Revoke with event_token
void PointerExited(event_token const* cookie) const;

// Revoke with event_revoker
UIElement::PointerExited_revoker PointerExited(auto_revoke_t, PointerEventHandler const& handler) const;
public event PointerEventHandler PointerExited;
function onPointerExited(eventArgs) { /* Your code */ }
uIElement.addEventListener("pointerexited", onPointerExited);
uIElement.removeEventListener("pointerexited", onPointerExited);
- or -
uIElement.onpointerexited = onPointerExited;
Public Custom Event PointerExited As PointerEventHandler 
<uiElement PointerExited="eventhandler"/>

Type d'événement

Remarques

L’événement PointerExited se déclenche en réponse à un pointeur qui se trouvait initialement dans la zone englobante de l’élément en laissant cette zone englobante. Les interactions tactiles, souris et stylet/stylet sont reçues, traitées et gérées en tant qu’entrée de pointeur dans l’application UWP. Chacun de ces appareils et leurs interactions peuvent produire un événement PointerExited. Pour plus d’informations, consultez Gérer l’entrée de pointeur et les autres remarques de cette rubrique.

Utilisez un gestionnaire basé sur PointerEventHandler pour gérer cet événement.

Pour les actions tactiles et pour les événements de manipulation ou spécifiques à l’interaction qui sont des conséquences d’une action tactile, un élément doit être visible au test de positionnement pour pouvoir être la source d’événement et déclencher l’événement associé à l’action. UIElement.Visibility doit être Visible. D’autres propriétés de types dérivés affectent également la visibilité des tests de positionnement. Pour plus d’informations, consultez Vue d’ensemble des événements et des événements routés.

PointerExited prend en charge la possibilité d’attacher des gestionnaires d’événements à l’itinéraire qui sera appelé même si les données d’événement de l’événement sont marquées Handled. Consultez AddHandler.

Des contrôles Windows Runtime spécifiques peuvent avoir une gestion basée sur des classes pour l’événement d’entrée PointerExited. Dans ce cas, le contrôle a probablement un remplacement pour la méthode OnPointerExited. En règle générale, l’événement n’est pas marqué comme étant géré par le gestionnaire de classe, l’événement PointerExited peut toujours être géré par votre code utilisateur pour le contrôle dans votre interface utilisateur. Pour plus d’informations sur le fonctionnement de la gestion basée sur les classes des événements, consultez Vue d’ensemble des événements et des événements routés.

Si un autre élément a capturé le pointeur, PointerExited ne se déclenche pas même si le pointeur capturé quitte les limites d’un élément. Pour plus d’informations sur la capture de pointeur, consultez Interactions avec CapturePointer ou souris.

PointerExited pour l’entrée de la souris et du stylet/stylet

Un périphérique d’entrée de souris a un curseur à l’écran qui est visible chaque fois que la souris se déplace, même si aucun bouton de la souris n’est enfoncé à ce moment-là. Un comportement similaire est disponible pour l’entrée de périphérique de stylet, où les périphériques d’entrée peuvent détecter que le stylet pointe juste sur la surface du périphérique d’entrée (IsInRange), mais ne le touche pas. L’entrée de périphérique de la souris et du stylet déclenche donc des événements PointerExited dans des cas légèrement différents de ceux des événements tactiles. Pour plus d’informations, voir Interactions avec la souris. Un événement PointerExited se déclenche après le dernier événement PointerMoved pour l’élément.

PointerExited pour l’entrée tactile

Un point tactile n’est détectable que si un doigt touche la surface. Chaque fois qu’une action tactile génère un événement PointerReleased , cet événement est immédiatement suivi d’un événement PointerExited, toutes les données d’événement étant les mêmes informations pour les deux événements (même ID de pointeur, même position, etc.) En d’autres termes, le pointeur est considéré comme entrant dans l’élément au moment et à la position où l’élément est touché par un point tactile.

Sinon, un point tactile génère PointerExited si ce pointeur reste en contact constant avec la surface à mesure qu’il se déplace, se trouve au-dessus de l’élément initialement, puis quitte les limites de test d’accès d’un élément. Pour ces types d’actions tactiles, il est également possible que l’action soit traitée comme une manipulation, ou comme un mouvement, plutôt qu’un événement de pointeur. Pour plus d’informations, consultez Gérer l’entrée de pointeur.

Comportement d’événement routé pour PointerExited

PointerExited est un événement routé. Pour plus d’informations sur le concept d’événement routé, consultez Vue d’ensemble des événements et des événements routés. Vous pouvez définir plusieurs événements PointerExited pour les éléments d’une interface utilisateur XAML, y compris pour les éléments qui se trouvent dans une relation parent-enfant. Dans une composition d’interface utilisateur classique, les éléments enfants se trouvent quelque part dans les limites d’un élément parent. Par conséquent, l’événement PointerExited se produit d’abord pour l’enfant lorsque le pointeur sort de l’enfant, puis pour le parent lorsque le pointeur sort complètement de ce parent. L’événement PointerExited n’est généralement pas en bulle vers le parent lorsque l’élément enfant le déclenche, car il serait confus pour le système d’entrée d’acheminer l’occurrence de l’événement PointerExited vers le parent également. En règle générale, vous ne souhaitez pas que les événements PointerExited soient acheminés de toute façon, vous souhaitez les traiter uniquement à partir de l’expéditeur. Vous pouvez explicitement empêcher le routage des événements en définissant Handled sur true dans votre gestionnaire.

Dans de rares cas, il est possible de voir une bulle d’événement PointerExited sur le parent. Par exemple, si vous avez utilisé un RenderTransform pour décaler un élément enfant en dehors des limites de son parent, l’événement est en bulles sur le parent lorsque l’élément enfant est quitté et donne les informations sur l’événement comme indiqué par la façon dont l’élément enfant a déclenché l’événement.

États visuels PointerOver pour les contrôles

Les contrôles qui ont des modèles de contrôle peuvent appliquer des états visuels qui sont actifs uniquement lorsqu’un pointeur se trouve au-dessus des limites du contrôle. Vous n’avez pas toujours besoin de gérer PointerEntered ou PointerExited pour obtenir ou modifier ce comportement. Vous devrez peut-être re-modèler le contrôle. Si vous dérivez d’un contrôle existant qui a déjà la gestion des entrées de bas niveau qui appelle des états visuels, vous devez fournir un état visuel nommé « PointerOver » dans le VisualStates « CommonStates » VisualStateGroup, et la logique de contrôle intégrée charge cet état visuel chaque fois qu’un pointeur se trouve sur le contrôle. Un état visuel pour le pointeur vers le dessus est souvent présent sur les contrôles qui peuvent être appelés ou sélectionnés, comme un Objet Button ou ListViewItem. Si vous dérivez d’une classe de base comme Control qui n’a pas de gestion des événements d’entrée intégrée qui appelle des états visuels, vous devrez peut-être remplacer OnPointerEntered et OnPointerExited vous-même pour obtenir ce comportement. Utilisez OnPointerExited pour appeler GoToState afin de charger un état autre que l’état « PointerOver », par exemple « Normal ». Pour plus d’informations, voir Animations dans une table de montage séquentiel pour les états visuels.

Comportement de Windows 8

Pour Windows 8, l’événement PointerEntered ne se déclenche généralement pas si le curseur à l’écran (stylet ou point tactile) n’a pas réellement été déplacé. Par exemple, PointerEntered ne se déclenche pas si la souris et son curseur à l’écran restent stationnaires, et qu’un objet avec un gestionnaire PointerEntered a sa position traduite ou ajustée pour se déplacer sous le curseur à l’écran. Ou , PointerEntered ne se déclenche pas si un élément comme une fenêtre contextuelle ou un menu volant disparaît et que le pointeur se trouve maintenant sur un nouvel élément (mais le pointeur n’a pas encore déplacé). Le comportement PointerExited est associé à cela. Par exemple, si une fenêtre contextuelle est ignorée par programmation, elle ne déclenche pas PointerExited si le pointeur n’a pas été déplacé comme cause de son rejet. Vous obtenez toujours un événement PointerEntered si le pointeur se déplace au-dessus de l’élément nouvellement révélé, mais c’est à l’utilisateur de décider si cela se produit au moment du déplacement, et non au moment du licenciement. En bref, la tentative d’utilisation du dernier élément qui a déclenché PointerEntered pour la détermination de l’état du pointeur dans l’interface utilisateur de l’application n’est pas complète dans Windows 8, et il existe de nombreux scénarios dans lesquels PointerEntered et PointerExited ne s’associent pas. Cela a un impact sur les états visuels des contrôles qui utilisent PointerEntered et PointerExited comme déclencheurs.

À compter de Windows 8.1, PointerExited est déclenché pour tous les cas où le pointeur a déclenché simultanément un événement PointerEntered, mais une modification de l’état de l’interface utilisateur se produit lorsque le pointeur ne se trouve plus dans cet élément. Cela inclut les cas où l’élément entier disparaît. Et si le pointeur se trouve maintenant sur un autre élément parce qu’un élément précédent a disparu, cet élément déclenche PointerEntered, même si le pointeur ne se déplace jamais. Les éléments qui définissent leur visibilité sur Collapsed par programmation sont l’une des façons dont les éléments peuvent disparaître de l’interface utilisateur, et le comportement Windows 8.1 en tient compte et déclenche PointerExited pour l’élément Collapsed et PointerEntered pour l’élément nouvellement révélé.

Si vous migrez votre code d’application de Windows 8 vers Windows 8.1 vous pouvez tenir compte de ce changement de comportement, car cela entraîne le déclenchement de PointerExited et PointerEntered dans les cas où ils n’auraient pas été déclenchés auparavant.

Les applications qui ont été compilées pour Windows 8, mais qui sont exécutées dans Windows 8.1, continuent d’appliquer le comportement Windows 8.

S’applique à

Voir aussi