UIElement.PointerEntered イベント
定義
重要
一部の情報は、リリース前に大きく変更される可能性があるプレリリースされた製品に関するものです。 Microsoft は、ここに記載されている情報について、明示または黙示を問わず、一切保証しません。
ポインターがこの要素のヒット テスト領域に入ったときに発生します。
public:
virtual event PointerEventHandler ^ PointerEntered;// Register
event_token PointerEntered(PointerEventHandler const& handler) const;
// Revoke with event_token
void PointerEntered(event_token const* cookie) const;
// Revoke with event_revoker
UIElement::PointerEntered_revoker PointerEntered(auto_revoke_t, PointerEventHandler const& handler) const;public event PointerEventHandler PointerEntered;function onPointerEntered(eventArgs) { /* Your code */ }
uIElement.addEventListener("pointerentered", onPointerEntered);
uIElement.removeEventListener("pointerentered", onPointerEntered);
- or -
uIElement.onpointerentered = onPointerEntered;Public Custom Event PointerEntered As PointerEventHandler <uiElement PointerEntered="eventhandler"/>
イベントの種類
注釈
PointerEntered イベントは、要素の境界領域に移動するポインターに応答して発生します。 タッチ、マウス、ペン/スタイラスの操作は、UWP アプリでポインター入力として受信、処理、管理されます。 これらのデバイスとその相互作用は、PointerEntered イベントを生成できます。 詳細については、「 ポインター入力の処理 」と、このトピックのその他の解説を参照してください。
PointerEntered はルーティング イベントです。 ルーティング イベントの概念の詳細については、「 イベントとルーティング イベントの概要」を参照してください。
PointerEventHandler に基づくハンドラーを使用して、このイベントを処理します。
タッチ操作や、タッチ操作の結果に発生する対話/操作イベントについては、ヒット テストで要素が表示されない場合、イベント ソースとして使用したり、操作に関連付けられたイベントを起動することはできません。 UIElement.Visibility はVisible である必要があります。 派生型の他のプロパティも、ヒット テストの可視性に影響します。 詳しくは、「イベントとルーティング イベントの概要」をご覧ください。
PointerEntered では、イベントのイベント データが Handled とマークされている場合でも、呼び出されるルートにイベント ハンドラーをアタッチする機能がサポートされています。 「 AddHandler」を参照してください。
特定のWindows ランタイム コントロールには、PointerEntered 入力イベントのクラスベースの処理が含まれる場合があります。 その場合、コントロールには OnPointerEntered メソッドのオーバーライドが含まれている可能性があります。 通常、イベントはクラス ハンドラーによって処理済みとしてマークされないため、PointerEntered イベントは UI のコントロールのユーザー コードで引き続き処理できます。 イベントのクラスベースの処理のしくみの詳細については、「 イベントとルーティング イベントの概要」を参照してください。
マウスとペン/スタイラスの入力用に PointerEntered
マウス入力デバイスには、画面上のカーソルがあり、その時点でマウス ボタンが押されていない場合でも、マウスが移動するたびに表示されます。 PointerEntered イベントは、 要素によって発生した最初の PointerMoved イベントの前に置きます。 ペン デバイスの入力でも同様の動作を使用できます。入力デバイスでは、スタイラスが入力デバイスサーフェス (IsInRange) の上にマウス ポインターを合わせてもタッチされていないことを検出できます。 したがって、マウスとペンのデバイス入力では、タッチ イベントとは少し異なるケースで PointerEntered イベントが発生します。 詳しくは、「マウス操作」をご覧ください。
タッチ入力用の PointerEntered
タッチ ポイントは、指がサーフェスに触れている場合にのみ検出できます。 タッチ アクションによって PointerPressed イベントが発生するたびに、そのイベントの直前に PointerEntered イベントが発生し、すべてのイベント データが 2 つのイベント (同じポインター ID、同じ位置など) に対して同じ情報になります。つまり、ポインターは、現時点で要素を入力し、要素がタッチ ポイントによってタッチされる位置を入力すると見なされます。
または、ポインターが移動する際にポインターがサーフェスと一定の接触を保ち、要素のヒット テスト境界に入ると、タッチ ポイントによって PointerEntered が生成されます。 このようなタッチ アクションの場合は、ポインター イベントではなく、操作またはジェスチャとしてアクションを処理することもできます。 詳細については、「 ポインター入力を処理する」を参照してください。
PointerEntered のルーティング イベントの動作
PointerEntered はルーティング イベントです。 ルーティング イベントの概念の詳細については、「 イベントとルーティング イベントの概要」を参照してください。 親子関係にある要素を含め、XAML UI の要素に対して複数の PointerEntered イベントを定義できます。 一般的な UI コンポジションでは、子要素は親要素の境界内に存在するため、ポインターが親に移動したときに PointerEntered イベントが最初に発生し、次にポインターが移動したときに子に対して PointerEntered イベントが発生します。 PointerEntered イベントは、通常、子要素が起動したときに親にバブルしません。これは、概念的にはポインターが既に親境界内にあり、入力システムが PointerEntered イベントの発生を親にルーティングする際に混乱を招く可能性があるためです。 通常、PointerEntered イベントをルーティングする必要はありません。送信者からのみ処理する必要があります。 ハンドラーで Handled を true に設定することで、イベント ルーティングを明示的に防止できます。
まれに、親への PointerEntered イベント バブルが表示される可能性があります。 たとえば、 RenderTransform を使用して子要素を親の境界の外側にオフセットした場合、子要素が入力されると、イベントは親にバブルし、子要素がイベントを発生させた方法によって報告されるイベント情報を提供します。
ポインター キャプチャ
別の要素がポインターをキャプチャした場合、キャプチャされたポインターが要素の境界に入っても、PointerEntered は起動しません。 ただし、ポインターが要素の上にあるときにポインター キャプチャが解放された場合、PointerEntered は起動します。この場合、ポインターが静止している可能性があるとさえ考えました。 イベント データからの GetCurrentPoint の値は、キャプチャが解放されたときにポインターが要素の上に既に存在するため、エッジに沿ったポイントではなく、要素の中央のどこかにあるポイントである可能性があります。 ポインター キャプチャの詳細については、「 CapturePointer または マウス操作」を参照してください。
コントロールの PointerOver ビジュアル状態
コントロール テンプレートを持つコントロールは、ポインターがコントロールの境界を超えている場合にのみアクティブな表示状態を適用できます。 この動作を取得または変更するために、PointerEntered または PointerExited を常に処理する必要はありません。 コントロールのテンプレートを再作成する必要がある場合があります。 ビジュアル状態を呼び出す低レベルの入力処理が既にある既存のコントロールから派生している場合は、"CommonStates" VisualStateGroup で "PointerOver" という名前のビジュアル状態を指定する必要があります。組み込みのコントロール ロジックは、ポインターがコントロールの上にあるたびにそのビジュアル状態を読み込みます。 ポインターオーバーの表示状態は、多くの場合、 Button や ListViewItem など、呼び出したり選択したりできるコントロールに存在します。 表示状態を呼び出す入力イベント処理が組み込まれていない Control などの基底クラスから派生している場合は、この動作を取得するために OnPointerEntered と OnPointerExited をオーバーライドする必要がある場合があります。 詳しくは、「表示状態用にストーリーボードに設定されたアニメーション」をご覧ください。
Windows 8 の動作
Windows 8 の場合、一般に、画面上のカーソル (スタイラスまたはタッチポイント) が実際に移動しなかった場合、PointerEntered イベントは発生しません。 たとえば、マウスと画面上のカーソルが静止したままで、PointerEntered ハンドラーを持つオブジェクトの位置が画面上のカーソルの下に移動するように変換または調整されている場合、PointerEntered は起動しません。 または、ポップアップやポップアップなどの要素が消え、ポインターが新しい要素の上に移動した (ただし、ポインターがまだ移動していない) 場合、PointerEntered は起動しません。 これに関連するのは、 PointerExited 動作です。 たとえば、ポップアップがプログラムで無視された場合、ポインターが無視の原因として移動しなかった場合、 PointerExited は発生しません。 新しく表示された要素の上をポインターが移動しても PointerEntered イベントが発生しますが、それが発生するかどうかはユーザーの責任であり、無視の瞬間ではなく移動時に発生します。 つまり、アプリ UI でポインター状態の決定に PointerEntered を発生させた最後の要素を使用しようとすると、Windows 8 では包括的ではなく、PointerEntered と PointerExited がペアにならないシナリオが多数あります。 これは、PointerEntered および PointerExited をトリガーとして使用するコントロールの表示状態にも影響します。
Windows 8.1以降では、ポインターが一度に PointerEntered イベントを発生させた場合に PointerExited が発生しますが、ポインターがその要素内になくなった場合に UI 状態の変更が発生します。 これには、要素全体が消える場合が含まれます。 また、前の要素が消えたためにポインターが別の要素の上にある場合、ポインターが移動しない場合でも、その要素は PointerEntered を起動します。 プログラムによって可視性を Collapsed に設定する要素は、要素が UI から消える可能性がある 1 つの方法であり、Windows 8.1の動作はこれを考慮して、Collapsed 要素に対して PointerExited が発生し、新しく表示された要素に対して PointerEntered が発生します。
アプリ コードを Windows 8 からWindows 8.1に移行する場合は、この動作の変更を考慮する必要があります。これは、PointerExited と PointerEntered が発生する前に発生しなかった場合に発生するためです。
Windows 8 用にコンパイルしたアプリは、Windows 8.1 上で実行しても Windows 8 のときと同じ動作になります。