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

StrokeIt 0.9.7

BUG: On Win7 x64, the wheel up/down gesture doesn't work properly on some 32 bit programs. Below are some of my test results. If there are more problem programs, please add to the list. Any chance this can be fixed in the future?

[32 bit programs]
no - photoshop cs4
no - maxthon 2.1.5
no - macro express 3.7d
no - dreamweaver cs4
works - zoom player 7
works - xnview 1.97
works - winamp 5.56
works - xplorer2 pro 1.7.2.6

[64 bit programs]
works - photoshop cs4
works - lightroom 2.5
works - perfectdisk 10
works - winrar 3.90
works - 3ds max 2010
works - notepad

I am not on Win 7, but I will pray for you that someone find a solution for this! Thank God for Autohotkey, anyway.

how do you fix this with autohotkey?

Hmm, actually I don't quite remember why exactly I said that. I think I said that because AHK is more reliable, that's why I use AHK to take over when SI cannot properly do some command. However, in this case I am unable to make it work as you wanted, alas. Perhaps someone more experienced with AHK could, though.

I tried to get a Wheel Up gesture to work, but I failed:

SI cannot perform any Wheel Up gestures at all on my computer, on Win XP 32.

I think I tried it and failed before, but that was long ago, when I thought it was my lack of experience that made me fail. However, this time I am sure I am doing it right, but the Wheel gesture triggers nothing, not even an OSD. I tried both global and some apps, such as Photoshop and Notepad++. The left mouse button gesture (hold right mouse button while pressing left button) does work, it is only the wheel that doesn't work.

The problem is not that my mouse is broken, because I can make [hold right button + scroll up] work through AHK. Unfortunately, I cannot get it to work through AHK without stealing the mouse hook from SI, which disables the right mouse button for gestures, which is unacceptable. So alas I have no solution.



Edited 3 time(s). Last edit at 07/05/2010 01:22PM by Cerberus.

Cerberus Wrote:
-------------------------------------------------------
> Hmm, actually I don't quite remember why exactly I
> said that.

I think you said that because of [url=http://www.tcbmi.com/strokeit/forum/read.php?3,54399,55078#msg-55078]this post[/url] one day before.

Ah, right! So AHK can help. However, on my PC, I cannot get StrokeIt to do anything by Wheel Up or Wheel Down, not even an OSD or a hotkey. I hold down Right Mouse button, scroll up or down, release RMB, but nothing happens. RMB is set as "draw gesture by holding ...".

Test {
   gesture = WHEEL_DOWN
   ss = osd, OSD  "Wheel down" "500" "96" "Algerian" "0" "255" "0" "1" "1"
}

RMB + LMB does work as it should.



Edited 1 time(s). Last edit at 07/05/2010 05:55PM by Cerberus.

so basically still no fix ?

I don't know - at least not for me, alas. And I still have no idea what causes this problem.

Allen Wrote:
-------------------------------------------------------
> so basically still no fix ?

No fix, but a workaround, see the link above. If you have problems to adapt the script, just ask.


@ Cerberus:
I think you're right, it seems to be not possible to assign RButton & Wheel to AHK and keep StrokeIt working. With StrokeIt active AHK is not able to detect the right button key state properly. Perhaps AHK could listen to wheel events and then check the color of StrokeIt tray icon. But I would prefer to assign LButton & Wheel or XButton1 (fourth mouse button) & Wheel.

has anyone figured out why this is a problem on window x64 for some 32 bit programs but not others? if we can pinpoint the issue, is there any way to get the developers to fix this in their programs?

can someone explain the workaround to this? is there a file to go with it? and can we edit that to our preferred commands?

I posted an example [url=http://www.tcbmi.com/strokeit/forum/read.php?3,54399,55078#msg-55078]here[/url], but let's try another one.

First you need a hotkey, which is not in use, for example "Ctrl + Alt + Shift + F2".

Set StrokeIt to send this hotkey on Wheel_Up on your affected app.

Then copy this code

#SingleInstance force
#Persistent 

~WheelUp::wheel=up
~WheelDown::wheel=down

^!+F2::                 ; if Ctrl + Alt + Shift + F2 is pressed
if wheel=up
  MsgBox, Wheel Up
else
  MsgBox, Wheel Down
return

to an editor and save it as "whatever.ahk".

If [url=http://www.autohotkey.com/]AutoHotkey[/url] is installed, you can doubleclick "whatever.ahk" and get a new tray icon.

Then go to your app and test Wheel_Up and Wheel_Down. Do you get message boxes?

What should happen on Wheel_Up and Wheel_Down?

how come strokeit has this issue but autohotkey doesn't? would the maker of strokeit be able to contact the maker of autohotkey and ask how to fix this issue on win7 x64? or copy the way autohotkey does it?

since this problem is caused by other 32 bit programs under 64 bit windows and is not natively a strokeit bug, i reported this problem to a few developers and below is a template anyone can use for reporting this bug. replace MYAPP32 with the name of the program affected and edit any other details as necessary. hopefully this will get the issue fixed by the developers of affected programs...

-----

BUG: MYAPP32 misrecognizes a command received from another program...

I use a free mouse gesture program called StrokeIt. It allows mouse gestures to be made for other programs. It uses mouse gestures and a few mouse click actions to activate custom commands.

But there is a bug in which MYAPP32 won't receive a command properly from StrokeIt. A StrokeIt command sent to MYAPP32 with the wheel_down mouse gesture is misrecognized by MYAPP32 as the same command used by the wheel_up gesture. The developer of StrokeIt has done a lot of testing on this problem and has concluded that this is a recognition bug in MYAPP32 under 64 bit Windows. Can this be fixed?

BTW: I'm currently using: Win7 x64 | MYAPP32 | StrokeIt Home 0.9.7

ALSO: To perform the wheel_down / wheel_up commands in StrokeIt, you hold down the right mouse button and scroll the wheel down/up. This will run whatever commands you have customized to that gesture.

anyone know how to contact jeff again about the problem? i'm not sure how often he checks the forum.

i reported the problem to adobe for photoshop CS5 32 bit and they wish to communicate with jeff to try solving the problem...

http://forums.adobe.com/message/3278506#3278506

Hi Allen!
Send him an email. His address can be found in the about box in StrokeIt

Allen Wrote:
-------------------------------------------------------
> BUG: MYAPP32 misrecognizes a command received from
> another program...

That's wrong, the affected apps do not misrecognize a command, they receive a wrong command.

You should report this to Microsoft. StrokeIt uses a windows method to detect wheel events, which under some conditions returns a wrong value.

Since you prefer not to explain your difficulties setting up the workaround, there might be no easy solution for you. However you could hope for a fix in Win7 Service Pack 1 (or SP2 / SP3).

wheel down doesn't work on Opera 10(x86) and Opera 11(x86) in X64 windows 7

This is happening to me as well on 32 and 64 bits apps on Win7.
Simply the wheel seems to send always the same command. I've set it to send hotkeys alt+tab on wheel up and alt+shift+tab on wheel down, but no matter the wheel direction it only sends alt+tab. Same thing goes if setting it to send the same commands but with keystrokes.
It happens always and with all my browsers (Opera 10, Fx 3.6, Chrome 5 and IE8. Also IE8 64 bits)

can this be fixed in a future version?

i did some more testing. on certain 32 bit programs on 64 bit windows, this is how the problem is behaving...

- wheel_up is being activated for when performing both wheel_up and wheel_down
- wheel_down isn't able to be activated at all

so the problem isn't that the wheel_down commands are misrecognized as wheel_up. because wheel_down isn't even working in the first place. but instead, wheel_up is malfunctioning and blocking wheel_down from working.

will there be a strokeit update to fix this bug?

Jeff has been away for some time now. When he comes back, let's pray he solves this! Meanwhile, I have no idea how it could be fixed. Good luck...

me,too!

Just got a new computer with win 7 x64 and noticed this problem with Opera. There is no good way of working around this with autohotkey either, wich was my first thought, problem is you'd need to disable all the opera gestures and im not willing to do that.

Why do you need to disable all the opera gestures? The [url=http://www.tcbmi.com/strokeit/forum/read.php?2,54969,55400#msg-55400]AutoHotkey script[/url] detects wheel up/down and waits for a hotkey triggered by StrokeIt. It doesn't interfere with any gestures.

The problem might have to do with Stroke It ; Just Gestures doesn't have it. Maybe because I used the 64 bit flavor, or they found a workaround. I have tried to use JG for the wheel movements. When the wheel is enabled in JG, Left and Middle button are captured too (even if they are explicitely disabled), so JG would have to be used for those actions too.

octaedro7 Wrote:
-------------------------------------------------------
> This is happening to me as well on 32 and 64 bits
> apps on Win7.
> Simply the wheel seems to send always the same
> command.

Cerberus Wrote:
-------------------------------------------------------
> Jeff has been away for some time now. When he
> comes back, let's pray he solves this! Meanwhile,
> I have no idea how it could be fixed. Good luck...


Pls @Jeff Fix this bug important needs for that Wheel UP/DOWN command ;)

Because of the Wheel up/down problem described here, I purchased the Pro version, to use button 4 and 5 instead of the wheel. I tried on Maxthon and IE, and found out that button 4/5 events are not handled at all on those programs.

I wanted to say thanks to Joe for his idea and examples with Autohotkey. It's perfect as a workaround for the wheel pb. Here is the ahk script I use to change tabs. I let Strokeit identify the application as they are of the same class.

#SingleInstance force
#Persistent 

~WheelUp::wheel=up
~WheelDown::wheel=down

^!+F2::        ; if ctrl + shift + alt + F2 is pressed (sent by Strokeit for Maxthon)
if wheel=up
  Send {F2}          ; previous tab
else
  Send {F3}          ; next tab                           
return

^!+F3::        ; if ctrl + shift + alt + F3 is pressed (sent by Strokeit for IE)
if wheel=up
  Send ^+{Tab}    ; previous tab
else
  Send ^{Tab}      ; next tab
return

test

Nice to hear that it works for you.

Ben Wrote:
-------------------------------------------------------
> Because of the Wheel up/down problem described
> here, I purchased the Pro version, to use button 4
> and 5 instead of the wheel. I tried on Maxthon and
> IE, and found out that button 4/5 events are not
> handled at all on those programs.

Not sure whether I understand it right: If you want to customize button 4/5 (trigger different actions depending on the active app), and if your mouse didn't come with software for this purpose (like "SetPoint" for Logitech mice), you could also use AutoHotkey for this. Button 4/5 is addressable as XButton1/2, for example:

#IfWinActive ahk_class IEFrame          ; if IE window is active
XButton1::                              ; when button 4 is pressed
MsgBox, You pressed button 4 in IE      ; you'll get a message box
return

Joe Wrote:
-------------------------------------------------------
> Not sure whether I understand it right: If you
> want to customize button 4/5 (trigger different
> actions depending on the active app), and if your
> mouse didn't come with software for this purpose
> (like "SetPoint" for Logitech mice),

I meant I wanted to use button4 and 5 while Rbutton is down (same as we discuss for the wheel in this topic), to do something like change tabs in Maxthon.

As a test, I configured StrokeIt so that button4 triggers an OSD globally (for all apps) - the pro version allows this and - it works fine... except when the active window is Maxthon or IE : nothing happens when using button4 while RButton is down. It looks like it's a bug in StrokeIt with some apps, similar to the bug with the wheel.


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. I'm going to try this right away. Would AHK allow to use them also in combination with Rbutton, in addition?


Anyway, I just noticed that my ahk script above, while working fine with Maxthon v1 and IE, does not work with Maxthon2. I'm far from knowing AHK well enough to have a clue what's causing this. For Strokeit, Maxthon 1 and 2 are identical as they are identified by their identical filename. And changing tab like my script does is triggered by the same function keys F2 and F3. Maybe you would have an idea?