From: Johnny Lee (typo_pl@hotmail.com)
Date: Mon Feb 17 2003 - 06:51:06 EST
The patches against HEAD and STABLE are attached. The actual non-whitespace
changes aren't very big.
I had to indent a bunch of code to make it look good which made the diffs
bigger than they really are.
Bug 3550:
When the document is >60 pages, the vertical scrollbar range > 16-bits.
But the windows message that the UI uses to handle mousewheel msgs only
allows 16-bits of info to be passed to the window proc.
To get around this, the scrollbar code currently scales this value up as
appropriate to get from the 16-bit pos to the actual pos.
Except in the mousewheel case, where the code was sending the actual desired
Y-coords. The window proc receives the message and proceeds to scale the
value up as it usually does. So the mousewheel ends up moving 2x as much. It
snowballs as you get further down the file.
When there's less than ~60 pages, the vertical scrollbar range fits into
16-bits so the scale factor is set to 1 which means no change occurs to the
scroll pos due to scaling.
Fix is to scale the value down before sending the scrollbar msg, since the
scrollbar code will scale the msg back up. this is the minimal change to fix
the bug. we lose some lower bits of info, but the code currently lives with
that Windows 16-bit limitation.
Bug 3845:
When you change the mousewheel to scroll down "one screen" at a time in the
Mouse control panel, Windows will now return WHEEL_PAGESCROLL (== UINT_MAX
== 0xFFFFFFFF) as the number of lines to scroll in one mouse wheel move.
We end up going in the opposite direction when the mouse wheel is moved
since UINT_MAX == -1 in signed math.
Fix is to look out for WHEEL_PAGESCROLL and treat the mouse wheel move as a
page scroll up or down as appropriate.
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
This archive was generated by hypermail 2.1.4 : Mon Feb 17 2003 - 06:55:54 EST