OnPointerEntered method
TOC
Collapse the table of content
Expand the table of content

Control.OnPointerEntered method

Called before the PointerEntered event occurs.

Syntax


Protected Overridable Sub OnPointerEntered(
  e As PointerRoutedEventArgs 
)

Parameters

e

Type: PointerRoutedEventArgs

Event data for the event.

Remarks

Windows 8 behavior

For Windows 8, generally the PointerEntered event won't fire if the onscreen cursor (or stylus or touchpoint) did not actually move. For example, PointerEntered doesn't fire if the mouse and its onscreen cursor remains stationary, and an object with a PointerEntered handler has its position translated or otherwise adjusted to move underneath the onscreen cursor. Or, PointerEntered doesn't fire if an element like a popup or flyout disappears and the pointer is now over a new element (but pointer hasn't moved yet). Related to this is the PointerExited behavior. For example, if a popup is dismissed programmatically, it won't fire PointerExited if the pointer didn't move as the cause of dismissing it. You would still get a PointerEntered event if the pointer moves while over the newly revealed element, but that's up to the user whether that will happen, and it happens at the time of movement, not the moment of dismissal. In short, trying to use the last element that fired PointerEntered for pointer state determination in the app UI isn't comprehensive in Windows 8, and there are many scenarios where PointerEntered and PointerExited won't pair up. This impacts the visual states for controls that use PointerEntered and PointerExited as triggers also.

Starting with Windows 8.1, PointerExited is fired for any case where the pointer had at one time fired a PointerEntered event, but some UI state change happens where the pointer is no longer within that element. This includes cases where the whole element disappears. And if the pointer is now over a different element because a previous element disappeared, that element fires PointerEntered, even if the pointer never moves. Elements that set their Visibility to Collapsed programmatically is one way that elements might disappear from UI, and the Windows 8.1 behavior accounts for this and will fire PointerExited for the Collapsed element and PointerEntered for the newly revealed element.

If you migrate your app code from Windows 8 to Windows 8.1 you may want to account for this behavior change, because it results in PointerExited and PointerEntered being fired in cases where they wouldn't have fired before.

Apps that were compiled for Windows 8 but running on Windows 8.1 continue to use the Windows 8 behavior.

Requirements (Windows 10 device family)

Device family

Universal, introduced version 10.0.10240.0

API contract

Windows.Foundation.UniversalApiContract, introduced version 1.0

Namespace

Windows.UI.Xaml.Controls
Windows::UI::Xaml::Controls [C++]

Metadata

Windows.Foundation.UniversalApiContract.winmd

Requirements (Windows 8.x and Windows Phone 8.x)

Minimum supported client

Windows 8

Minimum supported server

Windows Server 2012

Minimum supported phone

Windows Phone 8.1 [Windows Runtime apps only]

Namespace

Windows.UI.Xaml.Controls
Windows::UI::Xaml::Controls [C++]

Metadata

Windows.winmd

See also

Control
UIElement.PointerEntered
PointerRoutedEventArgs
Events and routed events overview
Custom user interactions
Handle pointer input

 

 

Show:
© 2017 Microsoft