Occurs when a right-tap input stimulus happens while the pointer is over the element.
RightTapped for a touch action results from processing an action that remains in one place for a certain amount of time. If it's a touch action, a Holding event from the same element always precedes this, but RightTapped won't fire until the touch point is released. If the time the pointer is pressed is too short and Tapped fires instead of Holding, or if the Hold action ends with HoldingState as Canceled, RightTapped won't fire.
RightTapped is the event to handle for displaying context menus. See Touch interaction design and Guidelines for common user interactions for more info on how to use a right-tap interaction in your app design.
A RightTapped event represents a gesture, whereas a PointerReleased event is a lower-level input event. RightTapped and PointerReleased events can fire as the result of a single user interaction. Even if a control is already handling pointer events in the control logic, or is handling manipulations, that doesn't prevent RightTapped from firing.
A RightTapped event is potentially the result of more than one pointer point. For the higher-level gesture events like RightTapped 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 RightTap from more than one pointer point.
RightTapped is a routed event. Also, an element must have IsRightTapEnabled be true to be a RightTapped event source (true is the default). It is possible to handle RightTapped on parent elements even if IsRightTapEnabled is false on the parent element, if the event bubbles to a parent from an event source child element where IsRightTapEnabled 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 and fire the event that is associated with the action. UIElement.Visibility must be Visible. Other properties of derived types also affect hit-test visibility. For more info, see Hit testing and input events.
Specific Windows Runtime controls may have class-based handling for the RightTapped event. If so, the control probably has an override for the method OnRightTapped. A right-tap action might be associated with displaying a context menu or secondary window. For more info on how class-based handling for events works, see Input event handlers in controls.
The input system processes an action where the user clicks the right mouse button while over the element as a RightTapped action. The event doesn't fire until the right 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.
Some pen devices have multiple buttons, one of which can be used the same way that the right button on a mouse device is used. This depends on the device and its settings, but if a right-click equivalent is enabled by the pen device, the input system can fire RightTapped for these actions also.
Windows 8 had an issue with the data for the RightTapped event, where the X and Y values for the point you'd get from RightTappedRoutedEventArgs.GetPosition were reversed (X was really Y; Y was really X). This issue has been fixed starting with Windows 8.1. But if you're retargeting a Windows 8 app for Windows 8.1, you might have had code that worked around this issue by swapping the X and Y back. If so, remove that code when you retarget because the issue is now fixed.
Apps that were compiled for Windows 8 but running on Windows 8.1 continue to use this Windows 8 behavior.
Also, Windows 8 didn't include default key handling for Shift+F10 that would fire this event and then display context menus. Shift+F10 is typically a secondary key combination for the VK_APP virtual key value (the Properties key), and thus Shift+F10 might be expected to fire RightTapped too. This issue has been fixed starting with Windows 8.1; Shift+F10 now fires RightTapped. You can see this change as default event handling on some controls that have default context menus for text, such as TextBox, or when invoking custom menus and flyouts.
Apps that were compiled for Windows 8 but running on Windows 8.1 do not use this Windows 8 behavior, they use the corrected Windows 8.1 behavior.
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
- Context menu sample