AutoHotkey Community

thanks Lexikos, just wanted to experiment how many programs and system utilities you could control/launch with a 2 button wireless mouse

will wait for the next version with anticipation

this works fine - Windows 7 x64 Master Volume

This is not working.

Gesture_L_U (left, up) - Up one level in Explorer/a file dialog.

at leas can you tell me what to write after this

Gesture_L_U

thank you

If you press Alt+Up, does it go up one level? If not, the gesture won't work either. It is implemented by the following line in Gestures.ini:

Hi - I'm trying to combine the gestures script with WindowPad, which seems to be working well:



However, I have a couple of questions:

Question 1 - I'm using the gesturekey "XButton1" (to avoid conflict with gestures in Firefox). However, I also want to remap XButton1 and XButton2 to PgDn and PgUp. I have accomplished this with the following code, but now run into the issue that I have to be very careful not to move the mouse when pressing XButton1, otherwise it triggers the gesture. Is there a better way to implement this PgDn functionality? How would I go about decreasing the sensitivity of the gestures? Also, is it necessary to add it to both "Gestures.ahk" and "Gestures Default.ahk"?



Question 2 - I would like to have more gestures triggered by another mouse button -- for example, XButton2. What would the most efficient way of implementing this be?

Question 3 - If I wanted to add rocker functionality, how should I go about doing this?

Thanks very much for the great script.

I just realised I got partway through revising the script, then forgot all about it.

<Edit>
Since I probably won't pick it back up anytime soon, I've uploaded the script as it is now and updated my original post. Changes include:

• Lots of rearranging. Gestures.ini no longer exists; gestures should be defined in Gestures_User.ahk. This file isn't included in the zip, but an example file is available. See my original post for more details.
• Support for trails on multiple monitors.
• An option do draw a small "notch" at the point where one stroke ends and the next begins (to make it clearer how the gesture is recognized).
• A few other options and various miscellaneous changes.

</Edit>

Try replacing ((m_StartX != m_EndX) || (m_StartY != m_EndY)) with (Abs(m_StartX - m_EndX) > m_LowThreshold || Abs(m_StartY - m_EndY) > m_LowThreshold), and tweak m_LowThreshold as necessary. m_LowThreshold defines the minimum distance the mouse must move before a gesture stroke can be recognized.
Add what? Gestures Default.ahk is #included in Gestures.ahk, so no.
Set m_GestureKey2=XButton2 in Gestures.ini or Gestures Default.ahk (or even Gestures.ahk). Then find the section in Gestures.ahk which builds the gesture string, and modify it so that m_LastGestureKey affects the result. The relevant section starts with this line:
<Edit> In the latest version, G_PerformAction() handles building the gesture string and executing the appropriate action. </Edit>
Which buttons do you wish to use? I avoid using typical rocker gestures (involving LButton & RButton) as it's difficult to do without interfering with the regular function of the button in some way.

Thanks for following up so promptly!



Maybe I'm looking in the wrong place, but it looks like the Gestures.zip file is still the old one? The newest files in it seemed to have been modified on June 2009.



LButton + RButton were the ones I wanted to use, but combinations of those with XButtons 1 & 2 would be fine as well. Some other gesture scripts seem to work well with rocker actions, so I was wondering how best to merge that functionality into yours.

Naturally, the download link would be the one part I forget to update. Fixed.

As for rocker gestures, perhaps my Gestures_User.ahk (link in original post) will be helpful. It use Gesture Key & XButton1/XButton2, XButton2 & LButton and XButton2 & RButton. It has to be a bit more complicated than normal custom combination to support using press and release of the "modifier" button itself. However, it might not work correctly if you use an XButton as the Gesture Key - you may need to add code in GestureKey_Down.

Scroll gesture was letting {%m_LastGestureKey% Up} pass when releasing the gesture button.


Placing that code into the GestureKey_Up sub will fix the problem.
If it takes longer than m_InitialTimeOut for you to scroll after pressing down the gesture key, it will send Gesture Key Up followed by escape upon release.
I had tried another fix in which no Gesture Key Up is sent, however it breaks the default gesture key's drag behavior most of the times... and since it's very unlikely that it takes me longer than 0.5s to start scrolling after hitting the g.k, i didn't bother to further research.

@Lexikos
Just out of curiosity ... I was wondering if you use your own gestures script, or perhaps have found a more efficient way to interact with your computer

@Webmaster
It makes no sense to me that i can post as guest from a tor exit node but i cant do so if i logged in. No tor, no post

I'm unable to replicate that.
As soon as m_InitialTimeout is reached during gesture recognition, the script breaks out of its loop and unregisters the wheel hotkeys. In other words, it won't recognize scrolling or any other action as a gesture at that point, so I can't see how your modification would work.

However, while testing your change I found a bug: m_ScrolledWheel is never reset. With your change, every time I right click it thinks I scrolled the wheel. Without your change, the only issue is that cancelling the gesture (by pressing Escape) unnecessarily waits for the button to be released before cleaning up.
I still use this script frequently.

I am afraid the fix is just suitable for my own heavily modified version of the old gestures.ahk.
I thought the original version had the same problem because g.k up event were sent "sometimes" upon g.k. release. Now i know that "sometimes" means only when waitcounter>InitialTimeout.


Ok. Once !m_StrokeCount && m_InitialTimeout && waitCounter > m_InitialTimeout it exits the loop (returns), but although in the autoexec section m_WaitForRelease is assigned a False value, somehow it remains true, so Scroll gestures wont just scroll but trigger the scroll gestures assigned action. (The same happened in my script with m_PassKeyUp thats why i needed to include if m_PassKeyUp && !m_ScrolledWheel into the GestureKey Up sub)

Unfortunately, I see myself very often pressing down the g.k. while still reading and thus starting to scroll when waitCounter > m_InitialTimeout. So the way I avoid %m_LastGestureKey% Up is taking this code out of the loop

and place it inside the grsture key up sub after "if ( !m_ScrolledWheel && !m_StrokeCount && m_InitialTimeout && waitCounter > m_InitialTimeout )".
This makes the default g.k drag behavior to be reproduced in one step (wont be able to see the selection rectangle.. and it just may fail)
Any suggestion on how to overcome this little trade off will be gratefully welcomed, but if still cant reproduce that.. better forget about it.


No wonder scroll gestures are ditched from the last Lex Gestures version. That may prevent some other newbies like me to mess around and come here to bother


Can't wait to try them . Hopefully it doesn't result in continuous high cpu usage.


Ever tried it? Really curious about it but unable to find reviews from people who got it

That you are using a heavily modified out-of-date version would explain why I can't reproduce the problem. Have you tried the latest version?
There's more to it. Depending on its parameters and when it is called, G_ExitGesture() sends the gesture key. If the key is still held down at the time, it sends only key-down and sets m_PassKeyUp to true so that when the key is released it won't be blocked. If you're using an old version it probably doesn't have G_ExitGesture(), and may or may not have similar behaviour.
It is set to true at the beginning of GestureKey_Down. Generally its value reflects whether the gesture key is in the pressed state.
m_PassKeyUp should only be set to true when G_ExitGesture() has sent a key-down. If you prevent it from sending key-up when m_PassKeyUp is true, the key will likely get stuck in the pressed state.
I had a similar issue when I started using a MX1100, which has a rather sensitive "free-spinning" wheel. It switches between that and normal mode at the click of a button, but since the free-spinning mode is far more convenient I generally leave it on that. Its extra buttons (and wheel tilt) are easier to use than wheel gestures anyway.
They aren't set by default, but that's because I don't find them useful, which may be a result of what I just said above. With the newest version, you may save the following as Gestures_User.ahk and place it in the same directory as Gestures.ahk:

Interesting concept, but the product itself isn't available yet.

You are right. The new version's G_ExitGesture solves all issues. Now it works perfect.
Thanks a lot for identifying the problem and pointing out a solution

Hi, Lex,
Your gesture script is very nice, though I have a few problems when m_PenWidth is set to draw mouse trail. It seems the GDI+ part can not redraw the screen quite properly.

I have also developed a mouse gesture script, which is good for showing mouse trail and prompts, but its functionality and structure are not as good as your.

Would you have a try and give me some feedbacks? Thanks!

Thanks for the update.

I'm still getting to know the newer version of your script but here are two minor bugs:

1. Line 40 ("m_EnabledIcon = ") in the example Gestures_User.ahk effectively removes the tray icon on my computer.
(maybe it should not be there, or it should read "m_EnabledIcon = %A_ScriptDir%\gestures.ico")

2. When the gesture key is pressed following a gesture the previous gestures trail briefly flashes on screen when trails are enabled,

_________________
Hardware: 1.8 GHz laptop with 4 GB ram, Windows XP/SP3
Software: Prevx, Privatefirewall, KeyScrambler.

What sort of problems?
My script does not use GDI+ at all, and does not "redraw the screen". However, it does place a "transparent" window over the entire screen - sometimes the transparency doesn't work correctly (esp. with less powerful systems), but unfortunately that's out of my control. I had considered an alternative for such cases, but not implemented it due to lack of time and interest. I also posted it in your thread:
That's basically what I already do, except that I allow the background to be painted and just make it transparent via WinSet,Transparent. Sometimes the WM_ERASEBKGND method doesn't work - an alternative is to paint a snapshot of the screen onto the window when it is initially shown.
That's the intended behaviour. I don't need to see when the script is enabled, only when it is not. Since I use AHKControl, the tray menu is always accessible.

Please note that Gestures_User.ahk is intended to contain your customizations, and should not be considered part of the main script. This is why it is not included in the ZIP.
This doesn't happen on my Windows 7 system. I noticed and fixed it on XP, but since I wasn't at home the script wasn't updated. I believe the fix was to find the following (which already exists in the script):
...and move it to G_ExitGesture:
I think I had originally written it this way, then moved it while attempting to resolve a similar, but intermittent issue.


Edit: I've updated the download with the change outlined above.