The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Control.OnRightTapped method

Called before the RightTapped event occurs.


protected virtual void OnRightTapped(
  RightTappedRoutedEventArgs e



Type: RightTappedRoutedEventArgs

Event data for the event.


OnRightTapped represents a prewired event handler for the UIElement.RightTapped event. Practical controls that derive from Control can override the OnRightTapped 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, OnRightTapped 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.

Windows 8 behavior

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 the 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.

Requirements (Windows 10 device family)

Device family

Universal, introduced version 10.0.10240.0

API contract

Windows.Foundation.UniversalApiContract, introduced version 1.0


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



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]


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



See also

Events and routed events overview
Custom user interactions
Handle pointer input