UIElement.AddHandler(RoutedEvent, Object, Boolean) メソッド

定義

指定したルーティング イベントのルーティング イベント ハンドラーを追加します。このハンドラーは、現在の要素のハンドラー コレクションに追加されます。 handledEventsToo をtrue として指定すると、イベントが他の場所で処理される場合でも、指定されたハンドラーを呼び出すことができます。

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)

パラメーター

routedEvent
RoutedEvent

ハンドルするルーティング イベントの識別子。

handler
Object

Platform::Object

IInspectable

ハンドラーの実装に対する参照。

handledEventsToo
Boolean

bool

ルーティング イベントがイベント データで処理済みとしてマークされている場合でも呼び出されるようにハンドラーを登録する場合は true。

ルーティング イベントが既に処理済みとしてマークされている場合に呼び出されない既定の条件にハンドラーを登録する場合は false。 既定値は false です。

ルーティング イベントは、制御合成のためのWindows ランタイム イベント システムの意図された設計に干渉するため、ルーティング イベントの再処理を定期的に要求しないでください。

この例では、AddHandler と handledEventsTootrue にしてイベント ハンドラーを配線するための基本的な構文を示します。 この場合、有線のイベントは タップされます。 ハンドラーをワイヤ化する一般的な場所は、ページの 場合は Loaded か、テンプレート化されたコントロールの 場合は OnApplyTemplate です。

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

注釈

イベント ハンドラーの配線に通常使用する言語固有の構文の一般的な代替として AddHandler を使用しないでください。すべてのイベントに routedEvent として渡すことができる識別子がないため、機能しません。 AddHandler は、ルーティング イベント専用であり、主に handledEventsTootrue として渡すことによって有効になる特定のシナリオを対象としています。 詳しくは、「イベントとルーティング イベントの概要」をご覧ください。

ルーティング イベント識別子

ルーティング イベント識別子は、通常、 UIElement の静的プロパティ メンバーです。 たとえば、 KeyUp イベントのハンドラーを追加するには、このパラメーターに KeyUpEvent を渡します。 この識別子を持つWindows ランタイムイベントはごくわずかです。UIElement のルーティング イベントにのみ、この使用に使用できる識別子 API があります。 これらは一般に、ポインター レベル、ジェスチャ レベル、操作レベルなど、さまざまなレベルの入力アクションに関連するイベントです。 また、キー入力イベントは、この方法で処理できます。

ルーティング イベント識別子を公開し、AddHandler 呼び出しによって登録されたハンドラーで処理できるルーティング イベントの一覧を次に示します。

handler パラメーター

handler パラメーターは型指定されていないパラメーターですが、目的のイベントに固有のハンドラー メソッドを参照する新しいデリゲートを指定する必要があります。 たとえば、 KeyUp イベントを処理する場合は、その KeyEventHandler デリゲート シグネチャに基づくメソッドを参照する新しい KeyEventHandler インスタンスを渡します。 これには逆参照が必要であり、逆参照構文は使用している言語によって異なります。 このトピックの例を参照してください。

handledEventsToo を使用するタイミング

低レベルの入力イベントを実用的な方法で処理するのは複雑な作業です。 多くのコントロールは、特定のイベントが処理済みとしてマークされ、別のより直感的なイベントに置き換えられる動作を実装します。 一般に、コントロールはルーティング イベントを処理済みとしてマークします。これは、これを行うための設計上の意図がある場合のみです。 ただし、特定のシナリオでは、これらの設計上の意図が、入力イベントの特定の処理に必要なものではありません。 これらのシナリオでは、 ハンドラーを handledEventsTootrue として登録することが適切です。 ただし、これを日常的に行うべきではありません。 処理された場合でも、すべてのイベントに応答してハンドラーを呼び出すと、独自のアプリのイベント処理ロジックが複雑になります。 ハンドラー ロジックが大幅に向上すると、パフォーマンスが低下する可能性があります。 特定のコントロールがアプリ ロジックで処理するイベントを処理していることが検出された場合にのみ、ハンドラーを既に処理されたイベントにアタッチする必要があります。

コントロールのクラス処理動作を回避するためのもう 1 つの手法は、そのコントロールをサブクラス化し、その OnEvent メソッドをオーバーライドすることです。これは、コントロールがイベントを処理済みとしてマークする事前構成済みのオーバーライドです。 ただし、これも複雑になる可能性があります。 基本実装ではイベントが処理済みとしてマークされるため、基本実装を呼び出さずにコントロールの処理実装を再現する必要がある場合があります。 詳しくは、「イベントとルーティング イベントの概要」をご覧ください。

適用対象

こちらもご覧ください