UIElement.PointerWheelChanged Event
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Occurs when the delta value of a pointer wheel changes.
public:
virtual event PointerEventHandler ^ PointerWheelChanged;// Register
event_token PointerWheelChanged(PointerEventHandler const& handler) const;
// Revoke with event_token
void PointerWheelChanged(event_token const* cookie) const;
// Revoke with event_revoker
UIElement::PointerWheelChanged_revoker PointerWheelChanged(auto_revoke_t, PointerEventHandler const& handler) const;public event PointerEventHandler PointerWheelChanged;function onPointerWheelChanged(eventArgs) { /* Your code */ }
uIElement.addEventListener("pointerwheelchanged", onPointerWheelChanged);
uIElement.removeEventListener("pointerwheelchanged", onPointerWheelChanged);
- or -
uIElement.onpointerwheelchanged = onPointerWheelChanged;Public Custom Event PointerWheelChanged As PointerEventHandler <uielement PointerWheelChanged = "eventhandler" .../>
Event Type
Remarks
When you handle PointerWheelChanged, you are usually interested in the MouseWheelDelta property value:
- Call GetCurrentPoint from the PointerRoutedEventArgs available to your handler. This returns a PointerPoint.
- Get the Properties of the PointerPoint. It contains a PointerPointProperties object.
- Get the MouseWheelDelta property value from the PointerPointProperties object. A positive value indicates that the wheel was rotated forward (away from the user) or tilted to the right; a negative value indicates that the wheel was rotated backward (toward the user) or tilted to the left.
If the element where pointer events occur has a non-default ManipulationMode value, then the action might also result in various manipulation events like ManipulationStarted. In addition, mouse wheel input can be handled as a built-in manipulation behavior by controls, even with no ManipulationMode value set. For example, certain controls like GridView and ListView can process mouse wheel input to initiate a scroll/pan action.
PointerWheelChanged is a routed event. 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.
PointerWheelChanged 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 PointerWheelChanged input event. If so, the control probably has an override for the method OnPointerWheelChanged. Typically the event is marked handled by the class handler, and the PointerWheelChanged event is not raised for handling by any user code handlers on that control. A control might do this in order to support traversal of its child elements by using a pointer wheel action. For more info on how class-based handling for events works, see Events and routed events overview.
Windows 8 behavior
For Windows 8, track pad device gestures that were input-handled by a ScrollViewer control part were interpreted as mouse wheel input, and thus would fire a PointerWheelChanged event. Starting with Windows 8.1, ScrollViewer uses an underlying manipulation logic that interprets track pad gestures as actions that the ScrollViewer responds to, and thus the gesture is considered handled by the control and the PointerWheelChanged event is not fired anymore.
If you migrate your app code from Windows 8 to Windows 8.1 you may want to account for this behavior change, because it results in PointerWheelChanged being fired in fewer cases. Also, the behavior that's now built-in to ScrollViewer may be duplicating what your handler would have done.
Apps that were compiled for Windows 8 but running on Windows 8.1 continue to use the Windows 8 behavior.