** Please check latest version from Wed Feb 02, 2011 10:12 am, it's on page 6 of this thread!! **
Some comments regarding your suggestions from the previous update, and how they have been incorporated into the latest update.
JohnCritton wrote:
You need to make a small change in the code to get the negative coordinates working.
Since you are now using m_x for the DLL call as well as for the lParam the masking must happen after the DLL call:
Code:
ControlClass1 := DllCall("WindowFromPoint", "int", m_x, "int", m_y)
m_x &= 0xFFFF
Otherwise the DLLCall will have the wrong m_x since it is using a 32Bit integer and not a 16Bit Integer like lParam.
Thanks for this, I’ve looked at it in more detail and now it all makes sense. An interesting observation is that when monitors are set up to be one above the other m_y may take negative values too. The good news is that this scenario is automatically covered!
JohnCritton wrote:
As for the 64Bit OS.
According to your comment in the code a 64Bit lParam is required. I don't know if MouseGetPos will return a 32Bit or 64Bit integer for m_x in a 64Bit OS.
If a 32Bit Integer is returned for m_x, the masking must not be done.
If a 64Bit Integer is returned for m_x, the masking must be changed to m_x &= 0xFFFFFFFF to preserve only the lower 32Bit of m_x an set the higher 32Bit to 0.
You are right. The latest update includes exactly that. I have upgraded the code to work on both 32-bit and 64-bit systems, based on the information found
here, as follows:
HotKeyIt wrote:
Code:
DllCall( "WindowFromPoint", "int64", m_x | (m_y << 32), "Ptr")
But this still needs testing...
grannyGrump NLI wrote:
I will test on my Vista 64-bit when I get home, and report any strange results.
Please do! If you can test this update on both your 32-bit machine and your 64-bit machine without modification just to check that the script really does work on both platforms.
JohnCritton wrote:
I have noticed a strange effect on the Main Pane of the AHK Help File (ClassNN: Internet Explorer_Server1). And only there.
Even so I have set Lines := 1 and both min and MaxLinesPerNotch to 1 there is some strange inertia effect. If I turn the MouseWheel in a fast motion, the Page continues scrolling for a few 100 ms even after the mouse wheel did stop. Similar to the effect know form iPhone and other touch devices.
No other Apps is showing this effect. The Index of the AHK Help is also working fine. When I stop the wheel, the scrolling stops immediately.
Very strange. Maybe you can have a look in to this.
I have read through the whole thread (I should have done this before...) and discovered that, while nobody got as far with this script as we have, they did identify some of the problems that we have encountered. The "momentum" or "drag" problem you describe, as you noticed, does not affect all apps.
1) AHK help: Without the script running, it works fine, but with the script Running, you get drag..
2) MS WordPad: You get drag wether or no the script is running! (XP Wordpad)
3) Notepad: No problems whether the script is running or not.
The problem arises when the app over which you are scrolling cannot catch up with the scroll commands being sent to it because they are being sent too rapidly. You'll find that most apps that have
smooth scrolling will exhibit this behaviour to some extent. Here's why:
1) WordPad: The app accepts the commands, but it's too busy doing the smooth-scroll eyecandy, so it buffers the commands for later execution. AHK keeps sending commands because WordPad accepts them, when in actual fact a bunch of the commands have not been executed yet. Unless smooth scrolling can be disabled, there is nothing we can do about these apps.
2) AHK Help: It refuses to accept further scroll commands until the current scroll command has been completed. In this case it becomes AHK's job to either buffer the scroll commands or trash them.
Luckily we can do something about this because we have full control over our scripts.3) Notepad: Notepad (and most apps) quite happily accepts quick scroll commands and executes them in real time, as it gives them high priority, and so scrolling is responsive.
This problem was actually pointed out long ago in this very thread!:
Laszlo wrote:
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)
Code:
#MaxThreadsBuffer On
#MaxThreadsPerHotkey 5
With this shorter memory there is no such a long scrolling period, after the whell was released.
Note that this problem also affects third-party focusless scrolling apps, but to a lesser extent, which made me think that it had to do with the way my previous script increased lines-per-notch by sending multiple scroll commands rather than by increasing the scrollstep directly, which resulted in more processing going on and therefore slower execution. However note that some GUI controls ignore the scroll-step value altogether, which means there would be no acceleration on some controls. The latest update has been optimized to take all this into account and ensures that all controls can be scrolled with acceleration, whilst drastically mitigating the momentum problem where required.
In addition I have added #MaxThreadsPerHotkey directives before and after your scrollwheel hotkeys, and removed the "Critical" command at the top of FocuslessScroll(), which is no longer needed. All of these improvements combined make the momentum problem almost unnoticeably, although it cannot be 100% removed.
I might be wrong but I don't think #MaxThreadBuffer On directive should be used (see the helpfile for details), unlike Laszlo's post suggests. Please prove me wrong though.
-Scoox
Login
Register
FAQ
Search
