Win7 x64, the wheel up/down gesture doesn't work properly on some 32 bit programs...

You could try to identify Maxthon2 using AU3_Spy.exe that is shipped with AHK or Winspector.

Regarding what can or cannot be done, SetPoint is a piece of sh#t compared to AHK. When I thought I've become skilled in AHK, my first task was to clone my SetPoint settings in AHK, add what I'd like to have but was impossible to achieve in SetPoint, then remove that useless garbage completely and throw its install disk as far as I could. Though I might go outside and search for that disk. Just to burn it to the ground :)

gemisigo Wrote:
-------------------------------------------------------
> You could try to identify Maxthon2 using
> AU3_Spy.exe that is shipped with AHK or
> Winspector.
>

Good idea, I thought Max1 and 2 were of the same class, but they are not.

Still, it doesn't seem to be the issue here. Max2 is correctly identified by StrokeIt and does receive events from AHK as proved by this test :

if I get AHK to send a MsgBox before sending the function key that will change the active tab (F2), like that:

if wheel=up
{
  MsgBox, F2  pressed             ; Send {F2} doesn't work without this msgbox here!?
  Send {F2}
}

I get the msg box and then, F2 changes the active tab as requested.

But if I send no test msg box or if I send it *after* sending F2, the active tab doesn't change. There might be someting wrong with the timing of the F2 key event, as it is delayed by the msg box. But I don't know what to do with this information.

I checked the code Joe posted and I don't see the reason to achieve your goal in such a complicated way (that is, throwing the control back and forth between SI and AHK). Why not simply using AHK code to do the job where SI fails?

~RButton & WheelUp::Send, {F2}
~RButton & WheelDown::Send, {F3}

Add necessary window class/title filter.

The code you're proposing implies control of Rbutton both in AHK and in SI. Joe tried this (I tried too), and apparently he couldn't get it to work (needless to say, me neither) :

Joe Wrote: July 08, 2010 09:21AM
-------------------------------------------------------
> @ Cerberus:
> I think you're right, it seems to be not possible
> to assign RButton & Wheel to AHK and keep StrokeIt
> working.


This is why he got SI to send some unused keys that AHK can intercept without having to listen to RButton. An my script does exactly that, as he did.

The difference between his approach and mine is, for him SI would send the same unused keys globally and let AHK do the filtering, based on class and/or title. My script is based on SI sending different unused keys based on application filtering done by SI. SI does that well, and that simplifies the filtering to be done in AHK.

The problem is that Max2 somehow doesn't receive the F2 key AHK sends its way. And it is sent its way correctly, as proved by displaying a msgbox instead of sneding F2.

Ben Wrote:
-------------------------------------------------------
> Still I like your idea to use AHK so that button4
> and 5 alone (without Rbutton pressed) depend on
> the active app :) Even with Setpoint (I have a
> G500) this is not possible as far as I know, only
> a global configuration is permitted.

SetPoint supports multiple profiles and you can assign different apps to different profiles. Not bad.

> Would AHK allow to use them
> also in combination with Rbutton, in addition?

The combination with RButton interferes with StrokeIt. I don't know an easy way to avoid this.


> MsgBox, F2 pressed ; Send {F2} doesn't work without this msgbox here!?
> Send {F2}

I would try to insert a delay before or/and after the Send command:

Sleep, 500
SendInput, {F2}
Sleep, 500

If it works, I would play with the values. In my scripts I often need a delay after the Send command.


gemisigo Wrote:
-------------------------------------------------------
> Regarding what can or cannot be done, SetPoint is
> a piece of sh#t compared to AHK. When I thought
> I've become skilled in AHK, my first task was to
> clone my SetPoint settings in AHK, add what I'd
> like to have but was impossible to achieve in
> SetPoint, then remove that useless garbage
> completely and throw its install disk as far as I
> could. Though I might go outside and search for
> that disk. Just to burn it to the ground :)

:) Don't use old install disks, there is a brand new version (from last week) with "numerous bug fixes and stability enhancements".

I don't think SetPoint is that bad. It works as expected here, and is easy to use.


> ~RButton & WheelUp::Send, {F2}
> ~RButton & WheelDown::Send, {F3}

RButton as the first part of a hotkey interferes with StrokeIt. Another approach I tried:

WheelUp::
GetKeyState, keystate, RButton
if keystate = D    ; D = down
  MsgBox, WheelUp while RButton down
else
  SendInput, {WheelUp}
return

The next problem is, RButton raises the context menu.

I didn't find a simple AHK only solution.

Sorry for misguiding then. It seemed logical though I must admit I never tried. I dusted my good ol' StrokeIt to check it and proved that the last one executed wins. But there are other combinations. You could just as easily use LButton/MButton/XButton1/XButton2 in combination (or on their own) with Wheel Up/Down/Left/Right.

AHK is a bit more sophisticated when it comes to identifying windows but this does not play here. Applying a little delay before sending is a good idea. You could try the different Send modes (SendInput, SendPlay, SendEvent) as well. They might work where Send fails. Also take note that due to User Interface Privilege Isolation the Send command might not work in a window that is running elevated if the script wasn't started with administrative privileges.

What really pissed me off in SetPoint was when I bought my brand new mouse, installed the new SetPoint that came with it, saw many awesome new features just to find out that they can only be assigned to the buttons of the new mouse. They were unavailable for the old one I used at home. And even using the new mouse they were not available for any button just for the selected 2. I thought that to be extremely dumb and decided to get rid of it. I'm happy now ;)



Edited 1 time(s). Last edit at 10/27/2011 03:11PM by gemisigo.

Thanks again Joe! Sleep works perfectly, and with as little as 40ms. I might try the various Send modes too later. I'm starting to like AHK.

As an alternative to Setpoint, XMBC http://www.highrez.co.uk/downloads/XMouseButtonControl.htm might help. It can assign Tilt Left and Right, in addition to Button4 and 5. I did not use it much yet.



EDIT: with SendEvent, sleep is not necessary



Edited 1 time(s). Last edit at 10/27/2011 05:14PM by Ben.

Nice ;) Though it's kinda funny since Send is synonymous to SendEvent. SendEvent applies a little delay after each keystroke. Which version of AHK is installed?

The screenshots of XMBC look good. And I guess it works with non-Logitech mice which is not true for SetPoint. I'll recommend it as a replacement. Thanks!

That's AutoHotkey_L, and when it creates a new file, it contains some statements that I kept, not knowing what they meant, as they were "recommended"

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn  ; Recommended for catching common errors.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

So unknowingly I was using SendInput

I see. Yes, those are the defaults. The third line makes Send default to SendInput which does not obey to SetKeyDelay settings (meaning there is no delay between keystrokes). This results in awkward behavior in some cases as you can see. But if you say by using SendEvent the script is working properly I recommend leave it that way. Thanks for the feedback, Ben.

Joe Wrote:
-------------------------------------------------------
> RButton as the first part of a hotkey interferes
> with StrokeIt. Another approach I tried:
> WheelUp::
> GetKeyState, keystate, RButton
> if keystate = D ; D = down
> MsgBox, WheelUp while RButton down
> else
> SendInput, {WheelUp}
> return

I tried this, but I found out that keystate is always Up (while strokeit is running)

You're right. I found that in my old test files, but didn't remember what I said [url=http://www.tcbmi.com/strokeit/forum/read.php?2,54969,55276#msg-55276]here[/url]:

> With StrokeIt active AHK is not able to detect the right button key state properly.

Same problem as before, one program controlles RButton and blocks it from all others.

It works when using the physical mode in GetKeyState though

GetKeyState, keystate, RButton, P

still the context menu pops up.....

Good idea! It seems to temporarily give the RButton control to AHK, as the StrokeIt icon doesn't turn to blue. Nice to know!

This AHK script:

; code page UTF8
#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn  ; Recommended for catching common errors.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.



#SingleInstance force
#Persistent


~XButton1::
GetKeyState, keystate, RButton, P
if keystate = D    ; D = down
{
	SendEvent ^x
}
return

~XButton2::
GetKeyState, keystate, RButton, P
if keystate = D    ; D = down
{
	SendEvent {Del}
}
return

works perfectly : it enables to use XButton in combination with the right button used by strokeit, and the context menu does not popup.

Is it the same for you?

I'm using SI Pro 9.7, AHK v1.1.05.04. under 7x64

If SI does not run, the context menu does popup. It does not when SI runs, even with all SI configuration erased, so this shouldn't be a side effect of using button 4 and 5 in SI somehow.

I'd like to get to the bottom of this, so that I can get the same behaviour when using a hotkey instead of XButtons. This would enable the use of other mouse buttons like tilt, that are not recognised by AHK but can trigger hotkeyd via the mouse driver.

What is strange is that I came across this script working for X2 by chance in a bigger script. But then it didn't work the same way with X1 : I was getting the context menu, even with the exact same code for both buttons. Stranger still, I isolated the code for X2 in its own script and I was getting the context menu again. It was working fine only in the bigger script.

Then while researching what was going on, the script above happened to work for both XButtons, and also worked when copied in the bigger script.

So I have a working script, but I'm not happy not to understand why, I don't want to lose that functionnality again, and I would like to extend it to hotkeys.

Your ideas would be appreciated.

So let me be sure. I wanted the right-mouse button/wheel up-down to change tabs in a text editor. But using Win7 64bit StrokeIt doesn't seem to work with Mouse Wheel Up/Down.

And this bug has been outstanding since Jan 4 2010???

Seems like this program has been abandoned!

I can get the Right Gesture to change tabs for example.

But I can't seem to get WHEEL_UP *OR* WHEEL_DOWN to do anything on any program with Win7 64bit SP1. 32bit and 64bit programs don't notice any WHEEL action. I tried this with Explorer and Directory Opus 64bit. So is this just SOME 32bit programs or is WHEEL_UP/DOWN broken?