| -api-id | -api-type |
|---|---|
E:Microsoft.UI.Xaml.UIElement.Holding |
winrt event |
Occurs when an otherwise unhandled Hold interaction occurs over the hit test area of this element.
<uiElement Holding="eventhandler"/>Touch can produce a Holding action, but mouse devices generally can't. For more info, see Handle pointer input.
The Tapped, DoubleTapped, and RightTapped events occur only after the touch point is removed. But the initial Holding event occurs while the touch point is still in contact. The event occurs if the touch point remains in approximately the same PointerPoint position for a period of time. The exact timing of what the system interprets as a holding action is adjustable by users through system settings.
Holding is intended for informational UI, but for interactions like displaying a context menu you should use RightTapped instead. You might handle Holding first to display a hint that a menu will appear, but to display the menu itself, use a RightTapped handler. See Touch interaction design or UX guidelines for custom user interactions for more info on how to use a Hold interaction in your app design.
Holding events generally occur in pairs. When the action is first interpreted as a Hold action based on no movement for a period of time, Holding fires, with HoldingState value of Started in the HoldingRoutedEventArgs event data. When the Hold action ends, another Holding event fires, this time with HoldingState of either Completed or Canceled.
-
The Hold action ends with HoldingState as Completed if the user doesn't move the pointer during the Hold state and then releases the pointer points that initiated the action. For this case, RightTapped fires just after the second Holding event.
-
The Hold action ends with HoldingState as Canceled if the user does move the pointer(s) that initiated the action, or also for uncommon situations such as changing the hit-test status on the element during the action or capturing another pointer. If the Hold action ends with HoldingState as Canceled, RightTapped won't fire.
A Holding event represents a gesture, whereas a PointerPressed event is a lower-level input event. Holding and PointerPressed 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 Holding from firing.
A Holding event is potentially the result of more than one pointer point. For the higher-level gesture events like Holding 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 Hold from more than one pointer point.
Holding is a routed event. Also, an element must have IsHoldingEnabled be true to be a Holding event source (true is the default). It is possible to handle Holding on parent elements even if IsHoldingEnabled is false on the parent element, if the event bubbles to a parent from an event source child element where IsHoldingEnabled 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 Events and routed events overview.
Holding 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 have class-based handling for the Holding event. If so, the control probably has an override for the method OnHolding. For more info on how class-based handling for events works, see Events and routed events overview.
Tapped and Holding are mutually exclusive. If the action passes the time threshold to be considered a Hold action, it's not considered to be a Tap action also.
Whenever Holding fires initially, so long as the element supports manipulation events through a non-default ManipulationMode value, ManipulationStarting fires too. If the pointer point remains in one place long enough for Holding to be detected, but thereafter the user moves the pointer points associated with the Hold action without releasing them (leading to another Holding event with HoldingState as Canceled), then other manipulation events like ManipulationStarted and ManipulationDelta can fire also.
Mouse input doesn't produce Holding events by default, no matter how long a mouse button is held down, or which button is held. However, mouse devices and some pen devices can fire RightTapped when a right mouse button or equivalent is pressed and released.
Note
There is a way to treat mouse actions as hold actions if you use your own GestureRecognizer and specify HoldWithMouse in settings.
HoldingRoutedEventArgs, RightTapped, OnHolding, IsHoldingEnabled, Handle pointer input, Events and routed events overview