Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

DragToScroll - Universal Drag & Fling/Flick Scrolling


  • Please log in to reply
210 replies to this topic
MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010
OK, getting the hang of debugging now :)

JDownloader is reporting the edge at several different spots, including the proper edge locations (20px of window border for me). The random edge tips in the middle of the window appear to be erroneous data from non-existent horizontal scrolling, it shows up a lot when I shift the mouse horizantally and shows up in other apps too. The vertical edge scrolling is being reported correctly, but no edge scrolling is taking place in JDownloader :? scrolling breaks off immediately when the cursor leaves the list area there may be some residual dragging after you leave the list area due to the WheelKey method being used.

MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010
Applied the latest update. It is doing what it should, flushing the variales, but app-specific disabling is now non-functional. Prior to the latest script 'app-specific disabling' would only kick in on the second drag (DtS would still scroll when dragged for the first time). Now it's not getting that second opportunity, the clean-up is making every drag the first drag.

:!: The problem is with 'app-specific disabling' not kicking in on the first drag in the disabled window!

cheek
  • Members
  • 71 posts
  • Last active: Jun 21 2014 03:24 AM
  • Joined: 01 Apr 2009

How do I achieve this? I've added this: ... to my INI file. Is that the proper way to retain global settings between updates?

I should have been more clear. The beta version as it stands is not actually supposed to do this yet; there are still some design issues to deal with before its fully implemented. The main issue with the current design is that in-memory changes made with the settings menus would be completely ignored.

That said, (most of) what you have is correct. The current design is that the General section will contain these settings, matching the variable names. You can save what you have, and (most of) it should work as you have it, when this feature is fully developed. Those settings will be loaded over any changes you make to the file (and thus kept between versions), but any changes you make with the settings menu will not do anything.

The only real problem is this:
Loop, %MaxAcceleration%
   Accel%A_Index%=.006 * A_Index **2 + 1

DoubleClickThreshold=DllCall("GetDoubleClickTime")
This is autohotkey code, and not valid INI syntax, which generally only allows for [sections], ;comments, and, name=value parameters.

Actually I'm not sure exactly WHICH settings you'll be able to control via the INI (as many as possible, i guess) and/or which settings are available for per-app customization. Not all variables really make sense to change per-app, like maybe Invert, or the binding button.

This release was mostly to start debugging the per-app settings. Now I'm glad I did, with all the issues coming up, but its still beta, and there are still apps that will refuse to cooperate regardless.

JDownloader is reporting the edge at several different spots, including the proper edge locations (20px of window border for me). The random edge tips in the middle of the window appear to be erroneous data from non-existent horizontal scrolling...

I'm going to have to add double checking the edge-scrolling code to my todo list. I have seen this behavior before, Notepad++ also shows its edge in random places.... Until now, this was the only app I'd seen that did it incorrectly. Still have a feeling its a problem with the app... I'll let you know if I find any bugs in this with the next release..

Edge scrolling is not designed to work with horizontal scrolling (buggy enough as it is ;)). DtS does not check for the left or right edges, should have nothing to do with edge scrolling. Many other apps report this correctly, try the edge scrolling tooltip in firefox to see what its supposed to do.

scrolling breaks off immediately when the cursor leaves the list area there may be some residual dragging after you leave the list area due to the WheelKey method being used.

This is probably expected, because youre using the WheelKey. As far as i can tell (also another double-check on my todo list) sending WheelUp cannot be done at a given coordinate without first virtually moving the mouse (always ugly)... So the scroll gets sent to whatever is under the cursor as you drag it around. I mentioned this in an earlier post, and would cause scrolling to stop if you "leave the listbox" to hover over the edge. This also depends somewhat on how applications handle the mousewheel; some apps may capture the wheel and send it to the topmost control and it will work, rather than only sending it to whatever is under the mouse (like the window border.)

Applied the latest update. It is doing what it should, flushing the variales, but app-specific disabling is now non-functional. Prior to the latest script 'app-specific disabling' would only kick in on the second drag (DtS would still scroll when dragged for the first time). Now it's not getting that second opportunity, the clean-up is making every drag the first drag. The problem is with 'app-specific disabling' not kicking in on the first drag in the disabled window!

Is it JUST the disable setting? I'll look more into this... Strange. I havent seen anything like this behavior. You may be able to get more insight into whats happening by turning on that tooltip in the GetSetting method... if you have an app-specific disable, it should show that its getting loaded in that tooltip. That's the first step, loading it.... You're using ScrollDisabled=true right?

cheek
  • Members
  • 71 posts
  • Last active: Jun 21 2014 03:24 AM
  • Joined: 01 Apr 2009
Ah, I found a major bug..
This hopefully will correct a lot of the issues around applying app specific settings, reliability in scrolling, the oddities around mutiple-monitors i was seeing, edge scrolling.. etc

I had written the script under the assumption that all coordinates referenced were relative to the screen. I had misread the documentation on CoordMode, and thought that screen relative was the default. To correct this, you just need to set the coordmode :oops:

CoordMode, Mouse, Screen

autohotkey.net beta has been updated, as well as the stable version in the first post.

MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010

...try the edge scrolling tooltip in firefox to see what its supposed to do.

The tooltip I'm getting occurs in every program I've tried it with (even Firefox), it happens sporadically on release of the drag button. It's basically a tooltip with no window coordinates:
: / ->   @Edge
I'm not sure it's a bug, since it shows up (any|every)where.
\
\

This is probably expected, because youre using the WheelKey. As far as i can tell (also another double-check on my todo list) sending WheelUp cannot be done at a given coordinate without first virtually moving the mouse (always ugly)... So the scroll gets sent to whatever is under the cursor as you drag it around. I mentioned this in an earlier post, and would cause scrolling to stop if you "leave the listbox" to hover over the edge. This also depends somewhat on how applications handle the mousewheel; some apps may capture the wheel and send it to the topmost control and it will work, rather than only sending it to whatever is under the mouse (like the window border.)

:?:I don't know if you've ever used Fast Picture Viewer; it has a setting that hides the mouse cursor when scrolling/dragging with the left or right buttons. This enables 'infinite scrolling', where the user can drag the mouse to scroll infinitely, by keeping the cursor in place. That would override WheelKey switching to other active (portions of) windows. WheelMessage also switches to spot under cursor in some programs [RARE]. Directory Opus is the only one I've encountered.
\
\

Is it JUST the disable setting? I'll look more into this...

ScrollDisabled=True is what I've been using. The tooltip doesn't display for that specific setting (and strictly that one alone; I haven't tried momentum, confine or invert; don't use them and don't think you have them app-specific yet).

MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010
The last update fixed the edge scrolling and active pane issues I was having with Thunderbird . :)

Is there a way to recognize the edges of specific window elements instead of the entire window? Or would that be too difficult? The Infinite Scroll method, described earlier, might be easier.

cheek
  • Members
  • 71 posts
  • Last active: Jun 21 2014 03:24 AM
  • Joined: 01 Apr 2009

It's basically a tooltip with no window coordinates

just comment out the tooltip, its not a "production" feature, just some quick info if youre hitting problems. ahk isn't a great language for debugging (no debugger), but taking some time to step through and understand other applications is a great way to build your skills.

a setting that hides the mouse cursor when scrolling/dragging with the left or right buttons. This enables 'infinite scrolling', where the user can drag the mouse to scroll infinitely, by keeping the cursor in place. That would override WheelKey switching to other active (portions of) windows.

this is certainly possible, and a good idea, but: I've tried forcing the mouse cursor to stay put, but that interferes with the dragging (and now movement checking) because, well, the mouse isn't moving. It's just not compatible with the way this is set up. I imagine that for that type of implementation, because the mouse pointer does not move, you need to track when it is moving, by receiving WM_MOUSEMOVE maybe, and keeeping track of all the positions yourself. It's just not really in the scope of this script.

Is there a way to recognize the edges of specific window elements instead of the entire window? Or would that be too difficult? The Infinite Scroll method, described earlier, might be easier.

I don't think that AHK can access control size and positions... However, if youre using WheelMessage & EdgeScrolling, this already works, you just click on the control to scroll and hover over the WINDOW edge, not the control edge. WheelMessage should send the scrolling to the clicked control (so long as the control does not move relative to the application.)

MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010

It's basically a tooltip with no window coordinates

just comment out the tooltip, its not a "production" feature, just some quick info if youre hitting problems. ahk isn't a great language for debugging (no debugger), but taking some time to step through and understand other applications is a great way to build your skills.

Was just elaborating to let you know what specific @edges I was seeing away from window edges. Figured it wasn't important. I obviously don't keep the debugging tooltips on all the time.

a setting that hides the mouse cursor when scrolling/dragging with the left or right buttons. This enables 'infinite scrolling', where the user can drag the mouse to scroll infinitely, by keeping the cursor in place. That would override WheelKey switching to other active (portions of) windows.

this is certainly possible, and a good idea, but: I've tried forcing the mouse cursor to stay put, but that interferes with the dragging (and now movement checking) because, well, the mouse isn't moving. It's just not compatible with the way this is set up. I imagine that for that type of implementation, because the mouse pointer does not move, you need to track when it is moving, by receiving WM_MOUSEMOVE maybe, and keeeping track of all the positions yourself. It's just not really in the scope of this script.

Thought this would be easier to implement, but yeah movement check would get in the way. Scroll Navigator also had this feature but like I posted before that app is buggy as hell regardless of any features it has.

Is there a way to recognize the edges of specific window elements instead of the entire window? Or would that be too difficult? The Infinite Scroll method, described earlier, might be easier.

I don't think that AHK can access control size and positions...

That's all I was wondering, bummer, thanks for the reply & all the updates to this script.

cheek
  • Members
  • 71 posts
  • Last active: Jun 21 2014 03:24 AM
  • Joined: 01 Apr 2009
Hi all,

Just posted another update to:
https://ahknet.autoh...ragToScroll.ahk

This should (hopefully) wrap up all of the bugs discussed in this thread lately, and adds the final implementation of persisted settings between releases. The GUI menus now also automatically saves your selections, so that if you "Reload" those preferences are persisted.

I'm going to play around with it--and let you do the same--for a few days, then I'll be packaging up the updated version into a zip with the required ini.ahk dependency, and updating the first post of this thread with these changes finalized.

Thanks for all the input,
let me know if anyone sees any problems with this update.

MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010
Thanks for updating cheek, really love using this script :D. Everything seems to be in order, works great!

:?: Could you make a post saying which settings are now app-specific
Not sure where/how to use this code, previously posted by you for getting any setting to be app-specific.
if (Get("ConfineToWindow") && WinHwnd != NewWinHwnd)
      GoSub DragStop


cheek
  • Members
  • 71 posts
  • Last active: Jun 21 2014 03:24 AM
  • Joined: 01 Apr 2009

:?: Could you make a post saying which settings are now app-specific?

Sure!

The App-specific behavior is all handled by the Get() method, you simply pass it the name of the setting, and it will go through your configuration and return one of; the app-specific value, your saved settings value, or my default.

Here are the settings currently using this behavior (I just did a search for "Get(")[*:210zk69x] ScrollDisabled
[*:210zk69x] SpeedX / SpeedY
[*:210zk69x] UseAccelerationX / UseAccelerationY
[*:210zk69x] ScrollMethodX / ScrollMethodY
[*:210zk69x] EdgeScrollSpeed

How to ... get any setting to be app-specific.

This is trivial, wherever you see the setting name, just wrap it in Get("SETTING_NAME"). Be aware however that this will incur a performance hit, so use it where necessary. Also, feel free to just ask me to include other settings to be per-app as well, and I will consider it for a future update.



I already have the next release nearly ready, and I may add more per-app settings. The next release adds automatic update checking at script load time, so you'll be aware of all these updates ;) I've got more ideas in the pipeline, but I think we're getting pretty close to being 'feature complete.' (Almost out of ideas!) I will be updating the first post soon. :)

MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010
Changed line 550 to
if (!Get("UseScrollMomentum"))
then entered UseScrollMomentum=1 for both Winamp and Firefox.
Momentum didn't get enabled for either app.

The GetSetting tooltip does not display anything for either app.

cheek
  • Members
  • 71 posts
  • Last active: Jun 21 2014 03:24 AM
  • Joined: 01 Apr 2009
I'm using an updated version, so our line numbers are slightly different. I've got the one from the zip file, available on the first page. The 'beta' url i was posting earlier is now taken down.

You missed one of the usages of UseScrollMomentum; you'll want to wrap all of them in Get(), except for in the menu handlers at the end.. all of the 'drag related' usages ;) I just do a Find for the variable name...
There's one in both of the DragMomentum: and the DragStop: labels.

This is a totally sensible setting to have per-app, will include this in the coming update.

cheek
  • Members
  • 71 posts
  • Last active: Jun 21 2014 03:24 AM
  • Joined: 01 Apr 2009
I posted that update, and have started adding version numbers. We're now on v2.0

This version brings automatic update checking, and adds more per-app settings. See the readme for the full list of changes.

MainTrane
  • Members
  • 41 posts
  • Last active: Jun 02 2011 08:52 PM
  • Joined: 13 Oct 2010
Thanks cheek,
DtS has come a long way, I'm liking the added options and features that arrive in each update :wink: