UIElement.AddHandler(RoutedEvent, Object, Boolean) Méthode

  • Référence

Définition

Espace de noms:
Windows.UI.Xaml
Modifier

Ajoute un gestionnaire d’événements routé pour un événement routé spécifié, en ajoutant le gestionnaire à la collection de gestionnaires sur l’élément actuel. Spécifiez handledEventsToo sur true pour que le gestionnaire fourni soit appelé même si l’événement est géré ailleurs.

public:
 virtual void AddHandler(RoutedEvent ^ routedEvent, Platform::Object ^ handler, bool handledEventsToo) = AddHandler;
void AddHandler(RoutedEvent const& routedEvent, IInspectable const& handler, bool const& handledEventsToo);
public void AddHandler(RoutedEvent routedEvent, object handler, bool handledEventsToo);
function addHandler(routedEvent, handler, handledEventsToo)
Public Sub AddHandler (routedEvent As RoutedEvent, handler As Object, handledEventsToo As Boolean)

Paramètres

routedEvent
RoutedEvent

Identificateur de l’événement routé à gérer.

handler
Object

Platform::Object

IInspectable

Référence à l’implémentation du gestionnaire.

handledEventsToo
Boolean

bool

true pour inscrire le gestionnaire de sorte qu’il soit appelé même lorsque l’événement routé est marqué comme géré dans ses données d’événement.

false pour inscrire le gestionnaire avec la condition par défaut qu’il ne sera pas appelé si l’événement routé est déjà marqué comme géré. La valeur par défaut est false.

Ne demandez pas systématiquement à rehanding un événement routé, car il interfère avec la conception prévue du système d’événements Windows Runtime pour la composition des contrôles.

Exemples

Cet exemple montre la syntaxe de base pour le câblage d’un gestionnaire d’événements avec AddHandler et handledEventsToo comme true. Dans ce cas, l’événement câblé est appuyé. L’emplacement classique pour les gestionnaires de câbles est Chargé pour une page ou OnApplyTemplate pour un contrôle avec modèle.

void MyControl::MyPointerPressedHandler(
    winrt::Windows::Foundation::IInspectable const &sender,
    winrt::Windows::UI::Xaml::Input::PointerRoutedEventArgs const& e) {
  // implementation..
}

this->AddHandler(
    winrt::Windows::UI::Xaml::UIElement::PointerPressedEvent(),
    winrt::box_value(winrt::Windows::UI::Xaml::Input::PointerEventHandler(this, &MyControl::MyPointerPressedHandler)),
    true);

// Or passing the handler as a lambda, instead of a member function:
this->AddHandler(
    winrt::Windows::UI::Xaml::UIElement::PointerPressedEvent(),
    winrt::box_value(winrt::Windows::UI::Xaml::Input::PointerEventHandler(
      [=](auto &&, winrt::Windows::UI::Xaml::Input::PointerRoutedEventArgs const &args) {
      // ...
    })),
    true);    

void MainPage::pageRoot_Tapped(Platform::Object^ sender, Windows::UI::Xaml::Input::TappedRoutedEventArgs^ e)
{
     //implementation
}
void MainPage::pageRoot_Loaded(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
     this->AddHandler(UIElement::TappedEvent, ref new TappedEventHandler(this, &MainPage::pageRoot_Tapped), true);
}

private void pageRoot_Tapped(object sender, TappedRoutedEventArgs e)
{
    //implementation
}
private void pageRoot_Loaded_1(object sender, RoutedEventArgs e)
{
    this.AddHandler(UIElement.TappedEvent, new TappedEventHandler(pageRoot_Tapped), true);
}

Private Sub Page_Tapped(sender As Object, e As TappedRoutedEventArgs)
    ' implementation
End Sub
Private Sub Page_Loaded_1(sender As Object, e As RoutedEventArgs)
    Me.AddHandler(UIElement.TappedEvent, New TappedEventHandler(AddressOf Page_Tapped), True)
End Sub

Remarques

N’essayez pas d’utiliser AddHandler comme substitut général de la syntaxe propre au langage que vous utilisez normalement pour le câblage des gestionnaires d’événements ; Cela ne fonctionnera pas, car tous les événements n’ont pas d’identificateur que vous pouvez passer en tant que routedEvent. AddHandler est spécifiquement destiné aux événements routés et est principalement destiné au scénario particulier activé en passant handledEventsToo comme true. Pour plus d’informations, consultez Vue d’ensemble des événements et des événements routés.

Identificateurs d’événement routés

L’identificateur d’événement routé est généralement un membre de propriété statique d’UIElement. Par exemple, pour ajouter un gestionnaire pour l’événement KeyUp , passez KeyUpEvent pour ce paramètre. Seul un petit nombre d’événements Windows Runtime ont cet identificateur ; seuls les événements routés sur UIElement disposent d’une API d’identificateur disponible pour cette utilisation. Il s’agit généralement d’événements liés aux actions d’entrée à différents niveaux : niveau pointeur, niveau de mouvement, niveau de manipulation. En outre, les événements d’entrée de clé peuvent être gérés de cette façon.

Voici une liste d’événements routés qui exposent un identificateur d’événement routé et qui peuvent donc être traités par des gestionnaires inscrits par un appel AddHandler :

Paramètre de gestionnaire

Le paramètre de gestionnaire est un paramètre non typé, mais vous devez fournir un nouveau délégué qui référence une méthode de gestionnaire spécifique à l’événement souhaité. Par exemple, si vous gérez un événement KeyUp, transmettez une nouvelle instance KeyEventHandler qui référence une méthode basée sur cette signature déléguée KeyEventHandler. Cela nécessite une déréférencement, et la syntaxe de déréférencement varie en fonction du langage que vous utilisez. Consultez les exemples de cette rubrique.

Quand utiliser handledEventsToo

Le traitement pratique des événements d’entrée de bas niveau est une tâche complexe. De nombreux contrôles implémentent un comportement où un événement est marqué comme géré et est remplacé par un autre événement plus intuitif. En règle générale, un contrôle marque un événement routé comme étant géré uniquement s’il y a une intention de conception de le faire. Toutefois, dans certains scénarios, ces intentions de conception peuvent ne pas être celles requises par votre gestion particulière de l’événement d’entrée. C’est pour ces scénarios que l’inscription des gestionnaires avec handledEventsToo comme true est appropriée. Mais vous ne devriez pas le faire régulièrement. L’appel de gestionnaires en réponse à tous les événements, même s’ils sont gérés, complique votre propre logique de traitement des événements d’application. Vous pouvez constater une baisse des performances si la logique du gestionnaire est importante. Vous devez attacher des gestionnaires à des événements déjà gérés uniquement si vous avez découvert que certains contrôles gèrent des événements que vous souhaitez gérer avec la logique d’application.

Une autre technique pour éviter le comportement de gestion de classes d’un contrôle consiste à sous-classe qui contrôle et remplace ses méthodes OnEvent , qui sont des remplacements préconfigurés par lesquels le contrôle marque un événement comme géré. Toutefois, cela peut également être complexe. Vous devrez peut-être reproduire l’implémentation de gestion d’un contrôle sans appeler l’implémentation de base, car l’implémentation de base marque l’événement comme étant géré. Pour plus d’informations, consultez Vue d’ensemble des événements et des événements routés.

S’applique à

Voir aussi