Partager via

Événements d’aperçu

  • 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 des événements en mode aperçu, soyez prudent quant à la façon de les marquer comme gérés dans les données de l'é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 de prévisualisation partagent également des instances de données d’événement avec l’événement de bouillonnement é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 comme gérés et gestion des classes.

Contournement de la suppression d'événements par les 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, un Windows Presentation Foundation (WPF) Button supprime les événements de bulle MouseLeftButtonDown et MouseRightButtonDown déclenchés par le Button ou ses éléments composites afin de capturer la souris et de déclencher un événement Click, qui est toujours déclenché par le Button lui-même. L’événement et ses données continuent toujours le long de l’itinéraire, mais parce que le Button marque les données d’événement comme Handled, seuls les gestionnaires de l’événement qui ont spécifiquement indiqué qu’ils doivent agir dans le cas handledEventsToo sont appelés. Si d'autres éléments vers la racine de votre application voulaient encore avoir la possibilité de gérer un événement contrôlé-supprimé, une alternative consiste à associer des gestionnaires directement dans le code avec handledEventsToo spécifié comme true. Mais souvent, une technique plus simple consiste à modifier le sens de routage que vous gérez pour qu'il devienne l'équivalent de prévisualisation d'un événement d'entrée. Par exemple, si un contrôle supprime MouseLeftButtonDown, essayez d’attacher un gestionnaire pour PreviewMouseLeftButtonDown à la 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 technique de handledEventsToo est que vous ne pouvez pas spécifier un gestionnaire handledEventsToo 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