DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR Pending]

Link: https://www.fltk.org/str.php?L3521
Version: 1.4-feature


Thanks for the patch and sorry for the delay on my side, I'm pretty busy
with other projects.

I tested the patch on Ubuntu 18.04 (as before in my VirtualBox VM, although
on another Windows 10 box) and it works as expected.

The Windows patch however inverts the scroll direction of Shift+Mousewheel
events.

Linux:   mousewheel down -> right, mouswheel up -> left  as expected.
Windows: mousewheel down -> left,  mouswheel up -> right *unexpected*.

We need to make this consistent across platforms. I believe this is due to
the "simple" patch approach that doesn't honor the /inverted/ wParam value
WRT WM_MOUSEWHEEL vx. WM_MOUSEHWHEEL events.

WM_MOUSEWHEEL: "A positive value indicates that the wheel was rotated
forward, away from the user; a negative value indicates that the wheel was
rotated backward, toward the user." [1]

i.e. positive -> up, negative -> down.

WM_MOUSEHWHEEL: "A positive value indicates that the wheel was rotated to
the right; a negative value indicates that the wheel was rotated to the
left." [2]

i.e. positive -> right, negative -> left.

So AFAICT the WM_MOUSEHWHEEL event implementation is correct but the
"simplified FALLTHROUGH patch" doesn't work correctly.

@Manolo: how does the (unpatched) macOS implementation of Shift+Mousewheel
work? Is it like the description of Linux above, or is it like the
(inverted) Windows description above?

------
[1] https://docs.microsoft.com/en-us/windows/desktop/inputdev/wm-mousewheel
[2]
https://docs.microsoft.com/en-us/windows/desktop/inputdev/wm-mousehwheel


Link: https://www.fltk.org/str.php?L3521
Version: 1.4-feature