UIElement.PointerEntered Événement
Définition
Important
Certaines informations portent sur la préversion du produit qui est susceptible d’être en grande partie modifiée avant sa publication. Microsoft exclut toute garantie, expresse ou implicite, concernant les informations fournies ici.
Se produit lorsqu’un pointeur entre dans la zone de test d’accès de cet élément.
public:
virtual event PointerEventHandler ^ PointerEntered;// Register
event_token PointerEntered(PointerEventHandler const& handler) const;
// Revoke with event_token
void PointerEntered(event_token const* cookie) const;
// Revoke with event_revoker
UIElement::PointerEntered_revoker PointerEntered(auto_revoke_t, PointerEventHandler const& handler) const;public event PointerEventHandler PointerEntered;function onPointerEntered(eventArgs) { /* Your code */ }
uIElement.addEventListener("pointerentered", onPointerEntered);
uIElement.removeEventListener("pointerentered", onPointerEntered);
- or -
uIElement.onpointerentered = onPointerEntered;Public Custom Event PointerEntered As PointerEventHandler <uiElement PointerEntered="eventhandler"/>
Type d'événement
Remarques
L’événement PointerEntered se déclenche en réponse à un pointeur se déplaçant dans la zone englobante de l’élément. 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 PointerEntered. Pour plus d’informations, consultez Gérer l’entrée du pointeur et les autres remarques de cette rubrique.
PointerEntered 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.
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.
PointerEntered 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 pour 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 PointerEntered. Dans ce cas, le contrôle a probablement un remplacement pour la méthode OnPointerEntered. 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 PointerEntered 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.
Pointeur Entré 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 événement PointerEntered précède le premier événement PointerMoved déclenché par l’élément . 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 du périphérique de la souris et du stylet déclenche donc des événements PointerEntered dans des cas légèrement différents de ceux des événements tactiles. Pour plus d’informations, voir Interactions avec la souris.
Pointeur Entré 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 PointerPressed , cet événement est immédiatement précédé d’un événement PointerEntered, 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.
Un point tactile génère également pointerEntered si un pointeur reste en contact constant avec la surface à mesure qu’il se déplace et entre dans 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 des événements routés pour PointerEntered
PointerEntered 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 PointerEntered 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, de sorte que l’événement PointerEntered se produit d’abord pour le parent lorsque le pointeur se déplace vers le parent, puis pour l’enfant lorsque le pointeur y se déplace. L’événement PointerEntered n’a généralement pas de bulles sur le parent lorsque l’élément enfant le déclenche, car conceptuellement, le pointeur se trouve déjà dans les limites parentes et il serait confus pour le système d’entrée d’acheminer l’occurrence d’événement PointerEntered vers le parent également. En règle générale, vous ne souhaitez pas que les événements PointerEntered soient routées 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 PointerEntered 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 entré 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.
Capture de pointeur
Si un autre élément a capturé le pointeur, PointerEntered ne se déclenche pas même si le pointeur capturé entre dans les limites d’un élément. Toutefois, si la capture de pointeur est relâchée alors que le pointeur se trouve au-dessus de l’élément, PointerEntered est alors déclenché, même si le pointeur est peut-être resté stationnaire dans ce cas. La valeur de GetCurrentPoint à partir des données d’événement peut être un point quelque part au milieu d’un élément plutôt qu’un point le long de ses bords, car le pointeur était déjà au-dessus de l’élément lors de la libération de la capture. Pour plus d’informations sur la capture de pointeur, consultez Interactions avec CapturePointer ou souris.
É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. 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 il 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.