AutoHotkey Community

[Laszlo]

[Laszlo]

Instead of buffering all the hotkeys with "critical", we can buffer only a certain number of them with the 2 lines below, added in front of the hotkey definitions (and removing critical)

[Laszlo]

This version seems to work the best, so far. It has geometrically increasing acceleration. Instead of SendMessage, it uses PostMessage, which does not wait for a response. Sleep 0 is used to give the application time to scroll. This way there is no need for buffering.

[Babis]

Very nice thanks

With the last script, in some progs like editplus, if I scroll hard, the scroll bar after reaches the end starts again from the beginning. Small bug maybe?

I love the acceleration.

[evl]

There's still the same problem with, if you scroll too fast, then you end up not scrolling as far as if you'd just scrolled slowly. It can probably be worked around with the acceleration / time since previous hotkey, but maybe Chris knows the exact cause of the wheel up/down hotkeys seemingly not receiving all events when scrolled very fast?

[Chris]

The answer may be that the system combines fast consecutive wheel turns into a single event with a larger-than-usual delta/movement parameter. If this is in fact what happens, AHK will only generate one WheelUp/Down hotkey event even when the delta is larger than usual.

I will investigate and try to come up with a solution. Thanks for pointing it out.

[evl]

Thanks for taking a look It can probably be worked around for a script like this (although it may be a bit ugly), but for other scripts that might need to keep a more accurate count it could be a big problem (at least worth mentioning in the manual if it can't be solved).

[Laszlo]

Chris: do you know why MouseGetPos returns a window ID which is different from what WindowFromPoint does? (My question a few posts ago.) It looks like the later returns the ID of the control. Who knew that controls have that, too?

But, we don't really need WindowFromPoint. MouseGetPos returns the window ID and the name of the control under the mouse pointer. If we use them both in SendMessage, it works:

[Chris]

[Laszlo]

Thanks, Chris. The Control, WinID combination from MouseGetPos seems to work, though.

Here is yet another experimental version. It starts with setting up the acceleration profile, in this case a geometrically increasing sequence from 1 to 250, stored in the array S. (Be careful, not to use too large values. They could be interpreted as negative by some applications.)

The hotkeys start with determining the speed of the wheel. It fluctuates strongly, therefore the average speed of the last two wheel events are computed and stored in the variable Speed. For that, we need to buffer one hotkey (#MaxThreadsPerHotkey 2); otherwise the speed computation would be wrong at fast turning wheel, when an event could be lost. The tick counter sometimes does not change between the hotkey routine activations, so we add 10 ms to the time difference. It avoids divisions with 0, and also limits the speeds values to be between 1 and 31 (with the numerator 300).

The distance, how much we want to scroll is dependent on the speed of the wheel. Its value is taken from the array S, and accumulated in the variable WCnt.

If the last wheel event was sent to the application within 30 ms, we just return, and will send the next wheel event with a larger scroll value. This way we don't send too many messages.

If enough time has passed since the last scroll, look where the mouse pointer is, and send the corresponding control a WM_MOUSEWHEEL message with the accumulated scroll amount in WCnt. Its sign (scroll up or down) is determined from the current hotkey name.

Most applications don't need to know the mouse position, but some, like MS Internet Explorer do not scroll, if the absolute screen coordinates are not included in the message, as two 16-bit values.

Sometimes, when the wheel is turned too fast, some mice randomly generate wheel events in the wrong direction. To make the script more robust, we could check if after WheelUp events there were a few WheelDown events within a very short time (or the other way around). If there were, we should ignore them, but let's fix possible other problems first.

[Chris]

In today's v1.0.43.03, mouse wheel hotkeys (WheelDown/Up) report the number of wheel turns in A_EventInfo, which allows distinguishing between fast and slow wheel movement.

Please give this a try and let me know if it helps enough. Thanks.

[Laszlo]

The A_EventInfo in mouse wheel hotkeys of AHK v1.0.43.03 works very well. Thanks, Chris!

The script below utilizes this new feature (this time with a linear acceleration profile). It is the simplest and the one closest in behavior to the original wheel handling of Windows, except, the control under the mouse pointer is scrolled, not the active one.

[evl]

I've tried testing both the short and longer versions but have found that PSPad and the main window in Avant Browser are ignoring the PostMessage - is there another way to scroll a control under the mouse? (I think Katmouse has some extra code to do with a few specific apps but, must use another method for generic programs like these).

[Laszlo]

How about Shimanov's solution?

[evl]

Well that just scrolls the active control in the active window (like normal windows behaviour), not the control under the mouse - which is why I use KatMouse in the first place.