opposite to the OS standard, the scroll-direction in horizontal mousewheel-scrolling is not in the way you move the wheel but in the other direction.
moving the wheel to the right moves the sight of the document to the left.
Is a known bug in OOo:
Can you describe what the OS standard behavior is? And what OS in particular are you referring to? Windows, Mac, KDE, Gnome etc?
As I tried to describe, the standard behavious is: Move the wheel to the right and the window scrolls to the right and vice versa.
In LO and OOo it's the other way around.
I'm using Win 7 Home Pro.
I think it's quite well discussed in the link I pasted.
Ah, so you have a special mouse with a horizontal wheel? I don't, and that's what confused me.
I cannot reproduce this in Linux (XServer) with a touchpad that has horizontal scrolling enabled. Can someone test it with a touchpad in MS Windows?
Ah ok, windows-only - so it seems then that vcl/win/source/window/salframe.cxx:3524 needs negation, in the horizontal case. Now just need the hardware ... ;)
can I help any further?
This is really driving my crazy.
Any more information needed?
Fixed by negating scroll values - cannot really verify the fix here, lacking the hardware.
Fridrich, any chance you can generate a tinderbox build from master at some time, and post the link here?
is the fix already included?
(In reply to comment #9)
> is the fix already included?
Yes, the fix is in master - in theory, http://dev-builds.libreoffice.org/daily/ should have daily builds of that. Fridrich, Tor, if at any time you'll have a master build ready, please point Hanni to it.
Sorry but where can I find a version of libreoffice where the bug is fixed?
(In reply to comment #11)
> Sorry but where can I find a version of libreoffice where the bug is fixed?
E.g. here: http://dev-builds.libreoffice.org/daily/Voreppe_Win32_Tinderbox/master/current/
Remove infoprovider from closed and resolved bugs.
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.