Vue d'ensemble des événements attachés

Extensible Application Markup Language (XAML) définit un composant de langage et le type d’événement appelé événement attaché. Le concept d’un événement attaché vous permet d’ajouter un gestionnaire pour un événement particulier à un élément arbitraire plutôt qu’à un élément qui définit réellement l’événement ou qui en hérite. Dans ce cas, ni l’objet qui déclenche potentiellement l’événement, ni l’instance de gestion de destination ne définit ou ne « détient » l’événement.

Prérequis

Cette rubrique suppose que vous avez lu vue d’ensemble des événements routés et XAML dans WPF.

Syntaxe d’un événement attaché

Les événements attachés ont une syntaxe XAML et un modèle de codage qui doivent être utilisés par le code de stockage afin de prendre en charge l’utilisation des événements attachés.

Dans la syntaxe XAML, l’événement attaché est spécifié non seulement par son nom d’événement, mais par son type propriétaire plus le nom de l’événement, séparé par un point (.). Comme le nom de l’évènement est qualifié avec le nom de son type propriétaire, la syntaxe de l’événement attaché permet à celui-ci d’être attaché à tout élément pouvant être instancié.

Par exemple, voici la syntaxe XAML permettant d’attacher un gestionnaire pour un NeedsCleaning événement attaché personnalisé :

<aqua:Aquarium Name="theAquarium" Height="600" Width="800" aqua:AquariumFilter.NeedsCleaning="WashMe"/>

Notez le préfixe aqua:. Ce préfixe est nécessaire dans le cas présent, car l’événement attaché est un événement personnalisé qui provient d’un fichier xmlns mappé personnalisé.

Comment WPF implémente des événements attachés

Dans WPF, les événements attachés sont sauvegardés par un RoutedEvent champ et sont routés via l’arborescence après leur déclenchement. En général, la source de l’événement attaché (l’objet qui déclenche l’événement) est une source système ou de service. L’objet qui exécute le code qui déclenche l’événement ne fait donc pas directement partie de l’arborescence d’éléments.

Scénarios pour les événements attachés

Dans WPF, les événements attachés sont présents dans certains domaines de fonctionnalités où il existe une abstraction au niveau du service, par exemple pour les événements activés par la Mouse classe statique ou la Validation classe. Les classes qui interagissent avec le service, ou qui l’utilisent, peuvent employer l’événement dans la syntaxe de l’événement attaché ou choisir de surfacer l’événement attaché en tant qu’événement routé faisant partie de la façon dont la classe intègre les fonctionnalités du service.

Bien que WPF définisse plusieurs événements attachés, les scénarios où vous allez utiliser ou gérer directement l’événement attaché sont très limités. En règle générale, l’événement attaché répond à un objectif d’architecture, mais est ensuite transféré à un événement routé non attaché (avec un wrapper d’événement CLR).

Par exemple, l’événement attaché sous-jacent Mouse.MouseDown peut être géré plus facilement sur tout donné UIElement en utilisant MouseDown sur, plutôt que de UIElement traiter la syntaxe de l’événement attaché en XAML ou dans le code. L’événement attaché a une fonction d’architecture, car il permet l’extension future des périphériques d’entrée. L’appareil hypothétique n’aurait besoin d’être déclenché que pour Mouse.MouseDown simuler l’entrée de la souris et n’aurait pas besoin de dériver de Mouse pour ce faire. Toutefois, ce scénario implique la gestion du code des événements, et la gestion XAML de l’événement attaché ne s’applique pas à ce scénario.

Gestion d’un événement attaché dans WPF

La gestion d’un événement attaché et le code du gestionnaire que vous allez écrire sont essentiellement les mêmes que pour un événement routé.

En général, un événement attaché WPF n’est pas très différent d’un événement routé WPF. Les différences sont le mode de source de l’événement et la façon dont il est exposé par une classe en tant que membre (ce qui affecte également la syntaxe du gestionnaire XAML).

Toutefois, comme indiqué précédemment, les événements attachés WPF existants ne sont pas particulièrement destinés à être pris en charge dans WPF. Le plus souvent, le but de l’événement est de permettre à un élément composé de signaler un état à un élément parent au moment de la composition. Dans ce cas, l’événement est généralement déclenché dans du code et compte également sur une gestion de classe dans la classe parente appropriée. Par exemple, les éléments d’un Selector sont censés déclencher l' Selected événement attaché, qui est ensuite une classe gérée par la classe, puis Selector potentiellement convertie par la Selector classe en un événement routé différent, SelectionChanged . Pour plus d’informations sur les événements routés et la gestion de classe, consultez Marquage des événements routés comme gérés et gestion de classe.

Définition de vos propres événements attachés en tant qu’événements routés

Si vous effectuez une dérivation à partir de classes de base WPF courantes, vous pouvez implémenter vos propres événements attachés en incluant certaines méthodes de modèle dans votre classe et en utilisant des méthodes utilitaires déjà présentes sur les classes de base.

Le modèle est le suivant :

  • Un Gestionnaire Add EventName de méthode avec deux paramètres. Le premier paramètre est l’instance à laquelle le gestionnaire d’événements est ajouté. Le deuxième paramètre est le gestionnaire d’événements à ajouter. La méthode doit être public et static , sans valeur de retour.

  • Un gestionnaire de méthode Remove EventName avec deux paramètres. Le premier paramètre est l’instance à partir de laquelle le gestionnaire d’événements est supprimé. Le deuxième paramètre est le gestionnaire d’événements à supprimer. La méthode doit être public et static , sans valeur de retour.

La méthode d’accesseur Add EventName Handler facilite le traitement XAML lorsque des attributs de gestionnaire d’événements attachés sont déclarés sur un élément. Les méthodes de gestionnaire Add EventName et Remove NomÉvénement permettent également d’accéder au code du magasin de gestionnaires d’événements pour l’événement attaché.

Ce modèle général n’est pas encore suffisamment précis pour une implémentation pratique dans une infrastructure, car toute implémentation de lecteur XAML donnée peut avoir des modèles différents pour identifier les événements sous-jacents dans le langage et l’architecture de prise en charge. C’est l’une des raisons pour lesquelles WPF implémente les événements attachés en tant qu’événements routés ; l’identificateur à utiliser pour un événement ( RoutedEvent ) est déjà défini par le système d’événements WPF. En outre, le routage d’un événement est une extension d’implémentation naturelle sur le concept de niveau de langage XAML d’un événement attaché.

L’implémentation du Gestionnaire Add NomÉvénement pour un événement attaché WPF consiste à appeler le AddHandler avec l’événement routé et le gestionnaire comme arguments.

Cette stratégie d’implémentation et le système d’événement routé en général restreignent la gestion des événements attachés à des UIElement classes dérivées ou à des ContentElement classes dérivées, car seules ces classes ont des AddHandler implémentations.

Par exemple, le code suivant définit l' NeedsCleaning événement attaché sur la classe propriétaire Aquarium , à l’aide de la stratégie d’événement attaché WPF qui consiste à déclarer l’événement attaché en tant qu’événement routé.

public static readonly RoutedEvent NeedsCleaningEvent = EventManager.RegisterRoutedEvent("NeedsCleaning", RoutingStrategy.Bubble, typeof(RoutedEventHandler), typeof(AquariumFilter));
public static void AddNeedsCleaningHandler(DependencyObject d, RoutedEventHandler handler)
{
    UIElement uie = d as UIElement;
    if (uie != null)
    {
        uie.AddHandler(AquariumFilter.NeedsCleaningEvent, handler);
    }
}
public static void RemoveNeedsCleaningHandler(DependencyObject d, RoutedEventHandler handler)
{
    UIElement uie = d as UIElement;
    if (uie != null)
    {
        uie.RemoveHandler(AquariumFilter.NeedsCleaningEvent, handler);
    }
}
Public Shared ReadOnly NeedsCleaningEvent As RoutedEvent = EventManager.RegisterRoutedEvent("NeedsCleaning", RoutingStrategy.Bubble, GetType(RoutedEventHandler), GetType(AquariumFilter))
Public Shared Sub AddNeedsCleaningHandler(ByVal d As DependencyObject, ByVal handler As RoutedEventHandler)
    Dim uie As UIElement = TryCast(d, UIElement)
    If uie IsNot Nothing Then
        uie.AddHandler(AquariumFilter.NeedsCleaningEvent, handler)
    End If
End Sub
Public Shared Sub RemoveNeedsCleaningHandler(ByVal d As DependencyObject, ByVal handler As RoutedEventHandler)
    Dim uie As UIElement = TryCast(d, UIElement)
    If uie IsNot Nothing Then
        uie.RemoveHandler(AquariumFilter.NeedsCleaningEvent, handler)
    End If
End Sub

Notez que la méthode utilisée pour établir le champ d’identificateur d’événement attaché, RegisterRoutedEvent , est en fait la même méthode que celle utilisée pour enregistrer un événement routé non attaché. Les événements attachés et les événements routés sont tous inscrits dans un magasin interne centralisé. Cette implémentation du magasin d’événements rend possible la considération conceptuelle des « événements en tant qu’interface » traitée dans Vue d’ensemble des événements routés.

Déclenchement d’un événement attaché WPF

En général, vous n’avez pas besoin de déclencher des événements attachés définis par WPF existants à partir de votre code. Ces événements suivent le modèle conceptuel « service » général, et les classes de service telles que InputManager sont chargées de déclencher les événements.

Toutefois, si vous définissez un événement attaché personnalisé basé sur le modèle WPF d’événements attachés de base sur RoutedEvent , vous pouvez utiliser RaiseEvent pour déclencher un événement attaché à partir de n’importe quel UIElement ou ContentElement . Le déclenchement d’un événement routé (attaché ou non) requiert que vous déclariez un élément particulier dans l’arborescence d’éléments comme source d’événement ; cette source est signalée comme RaiseEvent appelant. Votre service est chargé de déterminer quel est l’élément signalé en tant que source dans l’arborescence

Voir aussi