Pointer Wheel Changed Event
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 PointerWheelChanged_revoker PointerWheelChanged(auto_revoke_t, PointerEventHandler const& handler) const;
public event PointerEventHandler PointerWheelChanged;
Public Custom Event PointerWheelChanged As PointerEventHandler
<uielement PointerWheelChanged = "eventhandler" .../>
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.
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.