Aperçu des événements

  • Article

Les événements d’aperçu, également appelés événements de tunneling, sont des événements routés où la direction de l’itinéraire passe de la racine de l’application vers l’élément qui a déclenché l’événement et est signalée comme source dans les données d’événement. Tous les scénarios d’événements ne prennent pas en charge ou nécessitent des événements en préversion ; Cette rubrique décrit les situations où des événements d’aperçu existent, comment les applications ou les composants doivent les gérer, et les cas où la création d’événements d’aperçu dans des composants ou classes personnalisés peut être appropriée.

Aperçu des événements et des entrées

Lorsque vous gérez les événements en préversion en général, soyez prudent sur le marquage des événements gérés dans les données d’événement. La gestion d’un événement Preview sur un élément autre que l’élément qui l’a déclenché (l’élément signalé comme source dans les données d’événement) a l’effet de ne pas fournir à un élément la possibilité de gérer l’événement qu’il a généré. Parfois, il s’agit du résultat souhaité, en particulier si les éléments en question existent dans les relations au sein de la composition d’un contrôle.

Pour les événements d’entrée en particulier, les événements en préversion partagent également des instances de données d’événement avec l’événement de boublage équivalent. Si vous utilisez un gestionnaire de classes d’événements Preview pour marquer l’événement d’entrée géré, le gestionnaire de classes d’événements d’entrée de bubbling ne sera pas appelé. Ou, si vous utilisez un gestionnaire d’instances d’événement en préversion pour marquer l’événement géré, les gestionnaires pour l’événement de bubbling ne seront généralement pas appelés. Les gestionnaires de classes ou les gestionnaires d’instances peuvent être inscrits ou attachés avec une option à appeler même si l’événement est marqué comme géré, mais cette technique n’est pas couramment utilisée.

Pour plus d’informations sur la gestion des classes et leur relation avec les événements d’aperçu, consultez Marquage des événements routés en tant que handled et gestion des classes.

Résolution des problèmes liés à la suppression d’événements par des contrôles

Un scénario dans lequel les événements en préversion sont couramment utilisés est destiné à la gestion composite des événements d’entrée. Parfois, l’auteur du contrôle supprime un certain événement provenant de son contrôle, peut-être pour remplacer un événement défini par un composant qui contient plus d’informations ou implique un comportement plus spécifique. Par exemple, une Windows Presentation Foundation (WPF) Button supprime et MouseRightButtonDown déchauffe les événements déclenchés MouseLeftButtonDown par les éléments composites ou les Button éléments composites en faveur de capturer la souris et de déclencher un Click événement qui est toujours déclenché par lui-mêmeButton. L’événement et ses données continuent toujours le long de l’itinéraire, mais, étant donné que les Button marques des données d’événement sont définies comme Handled, seuls les gestionnaires de l’événement qui ont spécifiquement indiqué qu’ils doivent agir dans le handledEventsToo cas sont appelés. Si d’autres éléments vers la racine de votre application souhaitaient toujours gérer un événement supprimé par le contrôle, une alternative consiste à attacher des gestionnaires dans du code avec handledEventsToo spécifiés comme true. Mais souvent, une technique plus simple consiste à modifier le sens de routage que vous gérez pour être l’équivalent d’aperçu d’un événement d’entrée. Par exemple, si un contrôle supprime MouseLeftButtonDown, essayez d’attacher un gestionnaire à la PreviewMouseLeftButtonDown place. Cette technique fonctionne uniquement pour les événements d’entrée d’élément de base tels que MouseLeftButtonDown. Ces événements d’entrée utilisent des paires tunnel/bulles, déclenchent les deux événements et partagent les données d’événement.

Chacune de ces techniques a des effets secondaires ou des limitations. L’effet secondaire de la gestion de l’événement En préversion est que la gestion de l’événement à ce stade peut désactiver les gestionnaires qui s’attendent à gérer l’événement de bubbling, et par conséquent, la limitation est qu’il n’est généralement pas une bonne idée de marquer l’événement géré pendant qu’il est toujours sur la partie Aperçu de l’itinéraire. La limitation de la handledEventsToo technique est que vous ne pouvez pas spécifier un handledEventsToo gestionnaire en XAML en tant qu’attribut, vous devez inscrire le gestionnaire d’événements dans le code après avoir obtenu une référence d’objet à l’élément où le gestionnaire doit être attaché.

Voir aussi