Called before the PointerEntered event occurs.
Event data for the event.
OnPointerEntered represents a prewired event handler for the UIElement.PointerEntered event. Practical controls that derive from Control can override the OnPointerEntered method and use this to provide control-specific handling and behavior for that input event. The most common scenario is to use the event handler to mark the event as Handled in the event data. The control code has first chance to handle this event, before any event handlers that are wired on a control instance are invoked. When the event data is marked Handled, then other handlers like those on the control instance won't be called. Also, the event won't bubble. For more info, see the "On* event handler overrides" section in Control.
As it's implemented directly on Control, OnPointerEntered has an empty implementation. But each ancestor in a control's hierarchy may have provided an implementation. You won't be able to see this implementation because it's internal native code. In some cases a control will already have existing On* overrides that mark the event Handled. Once you've provided an initial On* override for a control, then any controls that you further derive from your own control class would also inherit the On* overrides you define. Any instances you use have that behavior too.
Note App code can still handle events that may have been marked Handled by a control's On* method logic, but they need to use the handledEventsToo parameter for the UIElement.AddHandler method. For more info, see UIElement.AddHandler or Events and routed events overview.
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.
Minimum supported client
Minimum supported server
|Windows Server 2012|
- Events and routed events overview
- Gestures, manipulations, and interactions
- Quickstart: Pointers