StrokesPlus.net Forum
»
Bugs or Issues
»
Bug Reports
»
Mouse Events (Hotkeys on X1, X2) sent twice
Rank: Member
Groups: Translators, Approved Joined: 11/7/2018(UTC) Posts: 18 Thanks: 1 times Was thanked: 1 time(s) in 1 post(s)
|
I'd like to put hotkeys on my extra mouse buttons X1 and X2 so I can switch between different desktops (CTRL+WIN+LEFT and CTRL+WIN+RIGHT).
It works ok, but the hotkeys are sent TWICE, one when I press the mouse button, one when I release it.
The script is this: sp.SendModifiedVKeys([vk.LCONTROL,vk.LWIN], [vk.LEFT]); // or "RIGHT"
I tried other hotkeys and they are always sent twice.
|
1 user thanked Roland for this useful post.
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Do you have this script in your X1/X2 Click Scripts? If so, this is not a bug, you just need to qualify the event. The script gets executed when the mouse button is pressed down, then again when released as someone may want to leverage things in a more complicated way. Code://Only fire on mouse down
if(click.Down) {
sp.SendModifiedVKeys([vk.LCONTROL,vk.LWIN], [vk.LEFT]); // or "RIGHT"
}
Code://Only fire on mouse up
if(!click.Down) {
sp.SendModifiedVKeys([vk.LCONTROL,vk.LWIN], [vk.LEFT]); // or "RIGHT"
}
|
|
|
|
Rank: Member
Groups: Translators, Approved Joined: 11/7/2018(UTC) Posts: 18 Thanks: 1 times Was thanked: 1 time(s) in 1 post(s)
|
Ah!!! Much better!
Thank you :)
|
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 5/6/2019(UTC) Posts: 111 Thanks: 19 times Was thanked: 1 time(s) in 1 post(s)
|
Dear Rob, the default function of my X1 in the mouse is backward. Can you disable the backward function when executing the script mentioned above?
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Unfortunately, these click scripts to not interfere with the mouse button messages, so Windows (or the mouse driver) will still receive them and respond.
You may need to find where the forward/backward are bound for the mouse and disable them.
I might consider adding that as an option, to just absorb mouse events for certain buttons.
|
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 5/6/2019(UTC) Posts: 111 Thanks: 19 times Was thanked: 1 time(s) in 1 post(s)
|
|
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 8/9/2019(UTC) Posts: 91 Thanks: 6 times
|
Originally Posted by: Rob Unfortunately, these click scripts to not interfere with the mouse button messages, so Windows (or the mouse driver) will still receive them and respond.
You may need to find where the forward/backward are bound for the mouse and disable them.
I might consider adding that as an option, to just absorb mouse events for certain buttons. Hey, this actually needs to be done for some software to function properly with StrokesPlus.net. Some software does not allow customizing [for example spefically] the X1 and X2 mouse buttons. Programmers simply hard-coded the functions for these buttons and it cannot be changed in any way. We need a way to intercept those buttons' clicks and stop them from propagating. I think that another "hooking" software, Event Ghost, has a specific action just for this, it's called Stop Processing Event, although I am not sure if it pertains only to EG processing of the event -- or ANY processing of the event in other software. Old Opera 12 on a medium-fast computer with StrokesPlus.net installed creates a problem with X1 and X2 button clicks when they are being clicked really fast. They not only register as a StrokesPlus.net actions but also as clicks inside Opera 12, which then goes forward/back in the page history. This is unwanted and Event Ghost can do this properly. So perhaps I can suggest a similar command which would bring us a way to stop further processing of the mouse button clicks that were just intercepted.
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
I agree, it's actually on my to-do list.
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Added Consume Click Event checkboxes in 0.3.3.3
|
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 8/9/2019(UTC) Posts: 91 Thanks: 6 times
|
Originally Posted by: Rob Added Consume Click Event checkboxes in 0.3.3.3 Thank you very much, I'll get to testing within 24 hours.
|
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 8/9/2019(UTC) Posts: 91 Thanks: 6 times
|
Originally Posted by: Rob Added Consume Click Event checkboxes in 0.3.3.3 testing goes really well but I have just realized there might be something missing. What if I have a game that uses the two X1 and X2 buttons? Won't they be converted to keystrokes/actions of strokesplus.net? In this case they should not be converted, actually. So I guess what is missing is the ability to assign actions to mouse buttons PER APPLICATION, because we may want to use them differently in different applications. Right now, even if I somehow modified the actions' script to distinguish between applications after clicking, the mouse click would still be consumed anyway (I thought you would make a script command but you made it as a checkbox -- which is FINE for global usage but could be detrimental for individual app usage). Other than that it works great so far. No hiccups yet, but we will see, it's still too early to say. Event Ghost hooks usually bug out on this within 2-3 days of use, so more time is needed for testing.
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Like everything, it always gets complicated and very per user :) The structure of the code doesn't easily lend itself to this request without major changes to the core code, however, you can still handle it via Global > Window Events > Foreground Window Change script. Code:if(TODO_LOGIC_TO_DETERMINE_IF_APP_IS_THE_GAME) {
sp_config.FireOnX1Click = false;
sp_config.ConsumeX1Click = false;
sp_config.FireOnX2Click = false;
sp_config.ConsumeX2Click = false;
} else {
sp_config.FireOnX1Click = true;
sp_config.ConsumeX1Click = true;
sp_config.FireOnX2Click = true;
sp_config.ConsumeX2Click = true;
}
Essentially, this will toggle off the X1/X2 scripts and click consume checkboxes if the foreground window meets the criteria (which still needs to be added), otherwise it enabled them. If your game uses those buttons, it's best that S+ not process them at all. You could actually send the mouse click directly from the script if it is the game using sp.MouseClick(click.Point, click.Button, click.Down, !click.Down); - but for a game, that's going to introduce slight delays which may be noticeable. This section is great to control things which are not app level, for example you could change ignore/stroke keys, disable certain global actions, really about anything you want. Edited by user Friday, August 16, 2019 1:01:08 PM(UTC)
| Reason: Not specified
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Oh, in the window change script, use sp.ForegroundWindow() to perform the logic for seeing if it's a game or whatever. There is no action object available in that script.
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
I can't make it a script command (well, not practical anyway) since the script fires immediately and on a new thread. It's best practice to very quickly process hooked events and call the next hook so as to not slow down input or in the case of an error in script, the hook would get evicted by Windows since it didn't receive a response and would also lock up the mouse until Windows evicted the hook.
|
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 8/9/2019(UTC) Posts: 91 Thanks: 6 times
|
Originally Posted by: Rob Oh, in the window change script, use sp.ForegroundWindow() to perform the logic for seeing if it's a game or whatever. There is no action object available in that script. Ok, so here is the script at Global Actions>>Window Events>>Foreground Window Change I have made using the logic you posted, thank you very much: Code:if(sp_config.FireOnX1Click == false && sp.ForegroundWindow().RootWindow.ClassName && sp.ForegroundWindow().RootWindow.ClassName == "OperaWindowClass"){
sp_config.FireOnX1Click = true;
sp_config.ConsumeX1Click = true;
sp_config.FireOnX2Click = true;
sp_config.ConsumeX2Click = true;
}
if(sp_config.FireOnX1Click == true && (!sp.ForegroundWindow().RootWindow.ClassName || sp.ForegroundWindow().RootWindow.ClassName != "OperaWindowClass")){
sp_config.FireOnX1Click = false;
sp_config.ConsumeX1Click = false;
sp_config.FireOnX2Click = false;
sp_config.ConsumeX2Click = false;
}
Everything works as it should except one small exception, not sure if it's related to the actual script above: when S+ is up and running try to click the tab of any program in the bottom tray bar (currently running programs - but not the right tray with tiny icons). This should make the program go fullscreen. Then click it again. This should minimize the program. Then click it again to maximize. While doing this, S+ sometimes bugs out with following: https://drive.google.com/open?id=1ycmaZgyJg5jBUYsa80zWA5-EdsTCW6HIThis also triggers the bug mentioned in the other thread where right clicking stops working when S+ is enabled. What is interesting is that it also bugged out in the same way (as if the scripts were running) when S+ was disabled :-O I had to turn off S+ completely to stop it from bugging out. Anyway, just keep clicking like mad the same bottom tabs in Windows (Win7 here) and it should surface.
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Click which button? Is there an associated X1 or X2 script or something in conjunction with the foreground window script?
|
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 8/9/2019(UTC) Posts: 91 Thanks: 6 times
|
Originally Posted by: Rob Click which button? Is there an associated X1 or X2 script or something in conjunction with the foreground window script? Click Left Mouse button (i.e. maximize and minimize window by clicking a program tab on bottom). Sorry for not being precise. As for associated scripts, yes, there are, of course. But nothing special. Just this: Code:if(click.Down) {
sp.SendKeys("{PgUp}");
}
I can easily break it by the above described clicking, so if you can't make it appear, I can make you a report with a debug version within 24 hours.
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Try 0.3.3.4.
The SystemWindow code (which I borrowed from another project) was throwing a zero error ("The operation completed successfully") if the WinAPI GetClassName function returned zero. Now it just returns an empty string instead of raising an error.
|
|
|
|
Rank: Administration
Groups: Translators, Members, Administrators Joined: 1/11/2018(UTC) Posts: 1,359 Location: Tampa, FL Thanks: 28 times Was thanked: 419 time(s) in 356 post(s)
|
Oh also, not that it should really matter, but I would use this code instead as it's far more efficient (less code calls for each reference): Code:var className = sp.ForegroundWindow().RootWindow.ClassName;
if(sp_config.FireOnX1Click == false && className && className == "OperaWindowClass"){
sp_config.FireOnX1Click = true;
sp_config.ConsumeX1Click = true;
sp_config.FireOnX2Click = true;
sp_config.ConsumeX2Click = true;
}
if(sp_config.FireOnX1Click == true && (!className || className != "OperaWindowClass")){
sp_config.FireOnX1Click = false;
sp_config.ConsumeX1Click = false;
sp_config.FireOnX2Click = false;
sp_config.ConsumeX2Click = false;
}
Edited by user Monday, August 19, 2019 1:51:43 PM(UTC)
| Reason: Updated to further reduce API calls
|
1 user thanked Rob for this useful post.
|
|
|
Rank: Advanced Member
Groups: Approved
Joined: 8/9/2019(UTC) Posts: 91 Thanks: 6 times
|
Originally Posted by: Rob Oh also, not that it should really matter, but I would use this code instead as it's far more efficient (less code calls for each reference): Code:var className = sp.ForegroundWindow().RootWindow.ClassName;
if(sp_config.FireOnX1Click == false && className && className == "OperaWindowClass"){
sp_config.FireOnX1Click = true;
sp_config.ConsumeX1Click = true;
sp_config.FireOnX2Click = true;
sp_config.ConsumeX2Click = true;
}
if(sp_config.FireOnX1Click == true && (!className || className != "OperaWindowClass")){
sp_config.FireOnX1Click = false;
sp_config.ConsumeX1Click = false;
sp_config.FireOnX2Click = false;
sp_config.ConsumeX2Click = false;
}
Hey, thanks for the modified code and for the fix. Works flawlessly now. Still testing though, too early to tell.
|
|
|
|
StrokesPlus.net Forum
»
Bugs or Issues
»
Bug Reports
»
Mouse Events (Hotkeys on X1, X2) sent twice
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
Important Information:
The StrokesPlus.net Forum uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close