Occurs when an otherwise unhandled Tap interaction occurs over the hit test area of this element.
public : event TappedEventHandler Tapped<>
// Register event_token Tapped(TappedEventHandler<> const& handler) const; // Revoke with event_token void Tapped(event_token const& cookie) const; // Revoke with event_revoker Tapped_revoker Tapped(auto_revoker_t, TappedEventHandler<> const& handler) const;
public event TappedEventHandler Tapped<>
Public Event TappedEventHandler Tapped( Of )
Touch, mouse devices and pen devices can all produce a Tap action. For more info, see Handle pointer 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 be raised as the result of a single user interaction. If the event source has a nondefault ManipulationMode, ManipulationStarting can be raised too. Even if a control is already handling PointerPressed in the control logic, or is handling manipulations, that doesn't prevent Tapped from being raised.
A Tapped event is potentially the result of more than one pointer point. For the higher-level gesture events such as 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 Events and routed events overview.
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 Events and routed events overview.
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 raises DoubleTapped, Tapped will be raised first to represent the first tap, but the second tap won't raise 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.
Tapped for mouse and pen/stylus input
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.
Controls that do not raise the Tapped event
These controls do not raise the Tapped event: