Occurs when an otherwise unhandled Tap interaction occurs over the hit test area of this element.
Touch, mouse devices and pen devices can all produce a Tap action. For more info, see Quickstart: Touch input.
See Touch interaction design for more info on how to use a Tap interaction in your app design. The general idea is that a Tap interaction on an element invokes the element's primary action in your app.
A Tapped event represents a gesture, whereas a PointerPressed event is a lower-level input event. Tapped and PointerPressed events can fire as the result of a single user interaction. If the event source has a nondefault ManipulationMode, ManipulationStarting can fire too. Even if a control is already handling PointerPressed in the control logic, or is handling manipulations, that doesn't prevent Tapped from firing.
A Tapped event is potentially the result of more than one pointer point. For the higher-level gesture events like Tapped you no longer have immediate access to PointerPoint details such as individual PointerId values or individual coordinates. You do have access to device type (PointerDeviceType) and for coordinates you can call GetPosition, which gives an average of the coordinates for a Tap from more than one pointer point.
Tapped is a routed event. Also, an element must have IsTapEnabled be true to be a Tapped event source (true is the default). It is possible to handle Tapped on parent elements even if IsTapEnabled is false on the parent element, if the event bubbles to a parent from an event source child element where IsTapEnabled is false. For more info on the routed event concept, see Events and routed events overview.
For touch actions and also for interaction-specific or manipulation events that are consequences of a touch action, an element must be hit-test visible in order to be the event source. UIElement.Visibility must be Visible. Other properties of derived types also affect hit-test visibility. For more info, see Hit testing and input events.
Tapped supports the ability to attach event handlers to the route that will be invoked even if the event data for the event is marked Handled. See AddHandler.
Specific Windows Runtime controls may also have class-based handling for the Tapped event. If so, the control probably has an override for the method OnTapped. For more info on how class-based handling for events works, see Input event handlers in controls.
Tapped and Holding are mutually exclusive. The input system must wait until the pointer point is released in order to determine whether the action should be Tapped, Holding or some other gesture, so you don't get Tapped at the very instant that a user touches the screen. If you really need instant feedback you may want to use PointerPressed instead.
If a user interaction also fires DoubleTapped, Tapped will fire first to represent the first tap, but the second tap won't fire an additional Tapped. If you want different logic for Tapped versus DoubleTapped, your Tapped handler may need to use app-specific variables and a timer in order to avoid running on interactions that are eventually interpreted as a DoubleTap action.
The input system processes an action where the user clicks the left mouse button while over the element as a Tapped action. The event doesn't fire until the left mouse button is released. Mouse input doesn't produce Holding events by default, no matter how long a mouse button is held down, or which button is held.
For pen devices, touching the pen device to the surface and remaining in one place produces a Hold action.
Minimum supported client
Minimum supported server
|Windows Server 2012|
Minimum supported phone
|Windows Phone 8.1 [Windows Runtime apps only]|
- Quickstart: Touch input
- XAML user input events sample