Called before the RightTapped event occurs.
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 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.
Minimum supported client
Minimum supported server
|Windows Server 2012|
- Events and routed events overview
- Gestures, manipulations, and interactions
- Quickstart: Pointers