Home Download Screenshots Wiki Plugins Translations Developers Donate Forums/Help Contact Us |
StrokeIt
Win7 x64, the wheel up/down gesture doesn't work properly on some 32 bit programs...Posted by Allen
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
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.
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.
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.
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 returnto 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?
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.
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).
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)
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?
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 returntest
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? |