StrokesPlus.net
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

2 Pages<12
Options
Go to last post Go to first unread
beholder  
#41 Posted : Monday, September 2, 2019 7:16:40 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
just a quick info: could not make it malfunction is so far, which is a good thing! Will be testing whole next day, so we will be sure then.
beholder  
#42 Posted : Monday, September 2, 2019 7:35:59 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
Originally Posted by: Rob Go to Quoted Post
For testing, I would suggest having Opera open and visible, and have another window as the foreground.
Move the mouse over Opera and click X1. Do that over and over to see if it gets stuck that way as well.

What is the code that you have in your X1 script?


Amazing, how did you know? This trick (Opera in bg, Chrome in front, click X2 or X1 over Opera) shows the Foreground Window notification bubble ALWAYS. Which probably means that there might be something going on with XButton1 going down and not going up immediately, because Foreground Window script unstucks it. Or at least says it does because there is no stuck overlay or anything, even after turning off FG script and doing the trick. This script:

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;
    // Allow a little time for other processing to happen
    sp.Sleep(25);
    if(sp.GetKeyState(vk.XBUTTON1) & 0x8000) { 
        sp.TraceLogEntry("X1 Down, Sending X1 Up (only sending up event)");
        sp.MouseClick(sp.GetCurrentMousePoint(), MouseButtons.XButton1, false, true);
        sp.ShowBalloonTip('Title', 'ALERT! Sending X1 Up check log!', 'Info', 15000);
    }
    if(sp.GetKeyState(vk.XBUTTON2) & 0x8000) { 
        sp.TraceLogEntry("X2 Down, Sending X2 Up (only sending up event)");
        sp.MouseClick(sp.GetCurrentMousePoint(), MouseButtons.XButton2, false, true);
        sp.ShowBalloonTip('Title', 'ALERT! Sending X2 Up check log!', 'Info', 15000);
    }

}
if(sp_config.FireOnX1Click == true && (!className || className != "OperaWindowClass")){
    sp_config.FireOnX1Click = false;
    sp_config.ConsumeX1Click = false;
    sp_config.FireOnX2Click = false;
    sp_config.ConsumeX2Click = false;
}


My X1 script has only a simple script:
Code:
if(click.Down) {
    sp.SendKeys("{PgUp}");
}
beholder  
#43 Posted : Monday, September 2, 2019 7:47:24 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
OMG, I think you just replicated it. Old StrokesPlus had this issue also btw. This is exactly it, the softcore version with foreground program clicks working but not on the taskbar, tray, etc.

The hardcore version where the "fullscreen" clicks are not accepted might be analogy of this but with some hard to track issue with some kind of window in front of other windows. Or something similar, it's still hard for me to wrap my head around this.

But you know your software, Rob; you do know your software... BigGrin

Originally Posted by: Rob Go to Quoted Post
By the way, it's very easy to confirm the X1 being down causes these issues.

Make an action of:
Code:
sp.MouseClick(sp.GetCurrentMousePoint(), MouseButtons.XButton1, true, false); 

Execute it and you'll see clicking/gestures don't work.

The X1 being down at the same time of clicking the mouse has very odd behavior like you're experiencing.
In fact, you can set the X1 to the down state and exit S+ and see the same results, until you press Ctrl+Alt+Del to reset input states:
Code:
sp.MouseClick(sp.GetCurrentMousePoint(), MouseButtons.XButton1, true, false); 
sp.Exit();

So what that means is that it has nothing to do with the S+ window/overlay/etc, it's all about the X1 button being considered in the down state.


Rob  
#44 Posted : Monday, September 2, 2019 9:33:06 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
Yeah, it's a race condition between the foreground window script and the mouse hook.

The mouse hook allows the X1 down event to pass because the foreground script hasn't yet set the X1 consume option. But by the time you release X1 the consume setting had been set by the foreground script, so the mouse hook consumes the up event which leaves the X1 button in a down state.

I'm about to go to bed, so I'll think on it some, but ultimately this will likely be something which will need to be addressed by scripts.

The S+ code is just doing what it's been instructed to do. While it may not make sense to do this most of the time, someone could want this type of behavior for some reason. I try not to have S+ make decisions or assumptions for anything outside of its own internal processes.

So now it's just a matter of figuring out the best way to handle this. Though I am concerned that there may not be an air tight method to handle the case of Opera in the bg and clicking X1 on it, but only in the context of consuming that initial down event since X1 is not set to be consumed yet.

You may just need to remove the foreground window script and leave the X1 script always enabled and always consuming. Then your X1 script would test if Opera and send Page Up/Down, else just send the X1 click manually. I have a feeling that would eliminate this issue with the button getting stuck due to the race condition.
Rob  
#45 Posted : Monday, September 2, 2019 9:41:45 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
Regarding the hooks and events. Windows sends two separate messages on mouse click.

One message for the button down. And another when you release.

A low level mouse hook receives these and tells Windows whether the message should propagate (let happen as normal) or if the message should not propagate (consume).

If the message is consumed, it's as if it never occurred. Windows, applications, nothing will see that message/event.

So you can imagine how the timing can cause this. The hook allows the down event to propagate, but consumes the up message sent after.

So Windows and all applications believe the X1 button is still being held down, since no up/release message was ever received/processed/propagated.

Edited by user Monday, September 2, 2019 9:43:41 PM(UTC)  | Reason: Not specified

beholder  
#46 Posted : Tuesday, September 3, 2019 1:14:48 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
one thing is not clear to me:

Buttons get stuck, allright. But why are they not immediately unstuck, when I physically clicked said buttons multiple times? Is there a special requirement for the unstucking that it must be done by a special script at special conditions?
beholder  
#47 Posted : Tuesday, September 3, 2019 1:54:49 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
Right now for example, I was able to bug it using the methods in this thread and the resulting state was that I was able to use X1 and X2 buttons in Opera normally but the Windows taskbar on the bottom didn't react to RMB or LMB. How is this possible when the X1 and X2 buttons are stuck?

post scriptum
(Yeah, I know, I should probably stop simplifying by using the word "stuck".)
Rob  
#48 Posted : Tuesday, September 3, 2019 11:34:48 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
I think if you're in Opera and the X1 script/consume options are enabled via the foreground window script, the S+ mouse hook will still receive the X1/X2 mouse events just fine.

It's other applications which may not receive a LMB or RMB if the X1 button is in a down state. I'm not sure about how Windows/etc handles these things at a very low level, the mouse hook just receives everything.

Have you tried what I suggested in terms of removing the foreground script and instead leaving the X1/X2 scripts always on an always consuming, and instead check the window in those scripts either send Page Up/Down or the default?
beholder  
#49 Posted : Tuesday, September 3, 2019 12:01:00 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
will do, the suggestion was lost to me in the deluge of other text.
beholder  
#50 Posted : Tuesday, September 3, 2019 12:25:24 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
So how do I actually consume the click in X1 and X2 events? The whole FW script was based on problem that this script in X1+X2 mouse events does not consume click and the mouse button is processed essentially "twice", once by script, once by Opera:

Code:
var className = sp.ForegroundWindow().RootWindow.ClassName;
if(className && className == "OperaWindowClass"){
    if(click.Down) {
        sp.SendKeys("{PgDn}");
    }
}

Shouldn't I add some kind of "else sp.clickLeftMouseButton()" to the code and check the "consume click" checkbox?
Rob  
#51 Posted : Tuesday, September 3, 2019 12:48:35 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
It will always consume the physical X1/X2 button events, you just change what happens when X1/X2 is clicked.

You either send Page Up/Down if Opera, otherwise you just send (relay) the click so the app sees the X1/X2 click events as they happened.

Note that the sp.MouseClick event is not consumed by S+ since it knows you're trying to send a click via script.

Code:
var className = sp.ForegroundWindow().RootWindow.ClassName;
if(className && className == "OperaWindowClass"){
    //If Opera and button is down, send Page Down
    if(click.Down) {
        sp.SendKeys("{PgDn}");
    }
} else {
    //If not Opera, send the event of the click along
    //This will send the Down or the Up event
    sp.MouseClick(click.Point, click.Button, click.Down, !click.Down); 
}


Edited by user Tuesday, September 3, 2019 12:51:59 PM(UTC)  | Reason: Changed script to use click.Point to be more efficient

beholder  
#52 Posted : Tuesday, September 3, 2019 1:07:32 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
The X2+X2 scripts with Consume Click Event do not work as intented:
When I loaded Chrome, make window to half-size and put in to foreground and active, then click X1 or X2 on Opera in background, it makes the X1 or X2 stuck. And it can't be unstuck in any way, bottom Windows pane just stops responding to any clicks.

I had to actually Ctrl+Alt+Del to Task Manager, then deactivate S+, then activate its foreground window script which unstuck the X1 or X2 key when I activated S+ and changed to different program.

I think you can easily replicate this by now, can't you?
Rob  
#53 Posted : Tuesday, September 3, 2019 1:19:59 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
Just to make sure, you don't have the foreground window change script still enabled, do you?
If so, it should not be.
beholder  
#54 Posted : Tuesday, September 3, 2019 1:31:29 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
No, of course not. I enabled it only when I needed to unstuck the X1 and X2 keys, after the bug actually manifested. It's nice that now I can resurface the bug ad libitum.
Rob  
#55 Posted : Tuesday, September 3, 2019 1:39:41 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
Unfortunately, my mouse has like 12 buttons on the left side and the back/forward ones don't fire as X1/X2, so I can't actually test any of these :/

I'll have to see if I have an old mouse somewhere.
Rob  
#56 Posted : Tuesday, September 3, 2019 1:56:14 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
Oh wait, you had Chrome as the foreground window. Try this instead as you want to test the window below the mouse cursor, not the foreground window.

Code:
var className = sp.WindowFromPoint(click.Point, true).RootWindow.ClassName;
if(className && className == "OperaWindowClass"){
    //If Opera and button is down, send Page Down
    if(click.Down) {
        sp.SendKeys("{PgDn}");
    }
} else {
    //If not Opera, send the event of the click along
    //This will send the Down or the Up event
    sp.MouseClick(click.Point, click.Button, click.Down, !click.Down); 
}


Now, I know there are two issues here, but I want to work them one at a time.

Edited by user Tuesday, September 3, 2019 1:56:46 PM(UTC)  | Reason: Not specified

beholder  
#57 Posted : Tuesday, September 3, 2019 3:00:56 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
Yeah, right, I see. We need to first activate the O12 window, if it is in background and the window on top of it has focus. But I guess it otherwise works ok for now. I will be now testing using system slowdown and disk activity.
beholder  
#58 Posted : Tuesday, September 3, 2019 3:14:50 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
The same problem under system stress: stuck mouse X buttons cause part or full screen unresponsive to clicking. Only gestures can be drawn but actions are not executed.

I did only some task switching (alt+tab) and clicking mouse buttons + did some gestures while loading a lot of stuff in Chrome when this happened.
beholder  
#59 Posted : Tuesday, September 3, 2019 3:20:53 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
BTW, during the unresponsive parts of screen, O12 window normally responded to X1 and X2 buttons (did page up and page down). So I guess the stuck buttons were again stuck at different programs, not in O12.
Rob  
#60 Posted : Tuesday, September 3, 2019 5:27:51 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
Opera isn't receiving or responding to mouse events during X1/X2, it only receives keyboard messages for page up/down.

I might need to expand the tracing to better capture these events. But I wonder if it's what I thought of last night, that under system stress those click threads are happening out of sequence or something, not sure.

Maybe in the X scripts, in the else, we only send the full click on the up or downevent, to eliminate that possibility. Will have to follow up when I'm on a computer to give you a script.

But basically you have the same if click.Down then send the mouse click, with the last two parameters of the sp mouse click being true, instead of click.Down, !click.Down

Then it would only send a full click each time in the same script execution. Not sure if that completely eliminates a possible race condition with queued up clicks under system stress, but maybe...?
beholder  
#61 Posted : Tuesday, September 3, 2019 6:18:40 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
Originally Posted by: Rob Go to Quoted Post
Opera isn't receiving or responding to mouse events during X1/X2, it only receives keyboard messages for page up/down.

I might need to expand the tracing to better capture these events. But I wonder if it's what I thought of last night, that under system stress those click threads are happening out of sequence or something, not sure.

Maybe in the X scripts, in the else, we only send the full click on the up or downevent, to eliminate that possibility. Will have to follow up when I'm on a computer to give you a script.

But basically you have the same if click.Down then send the mouse click, with the last two parameters of the sp mouse click being true, instead of click.Down, !click.Down

Then it would only send a full click each time in the same script execution. Not sure if that completely eliminates a possible race condition with queued up clicks under system stress, but maybe...?


So I added the 2nd line of sp.MouseClick() after the 1st one, like this:
Code:
    sp.MouseClick(click.Point, click.Button, click.Down, !click.Down); 
    sp.MouseClick(click.Point, click.Button, true, true);

However the results didn't differ from previous ones, I got 1 case of self-recovered stuck mouse buttons for 10 seconds and 1 case of really hard lock down, which I could only break by beforementioned process; task manager unbound the LMB, disable S+, enable FG script, save S+, alt+tab (FG script does not need S+ enabled), RMB works.

The only thing that positively fixed this is an alt+tab while that FG script is active. It obviously runs for each program and checks for a stuck button in each FG program, then unstucks it. It does this REGARDLESS of other buttons pressed, it runs always on switching the focus and that is its strength.
Rob  
#62 Posted : Tuesday, September 3, 2019 7:50:12 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 433
United States

Thanks: 5 times
Was thanked: 84 time(s) in 72 post(s)
Having two mouse click calls would not help, I meant to replace it.

Try this and see what happens, it uses some stored booleans to help keep two scripts from executing at the same time as well.

Code:
var ct = 0;
while(sp.GetStoredBool("XClick")) {
    sp.Sleep(10);
    ct++;
    if(ct > 100) break;
}

if(ct <= 100) {
    sp.StoreBool("XClick", true);
    var className = sp.WindowFromPoint(click.Point, true).RootWindow.ClassName;
    if(className && className == "OperaWindowClass"){
        //If Opera and button is down, send Page Down
        if(click.Down) {
            sp.SendKeys("{PgDn}");
        }
    } else {
        //If not Opera and button is down, send full X click
        if(click.Down) {
            sp.MouseClick(click.Point, click.Button, true, true); 
        }
    }
    sp.StoreBool("XClick", false);
}
beholder  
#63 Posted : Tuesday, September 3, 2019 8:25:17 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
So far so good, I was not able to break it while testing it for a short while, because I have to GTFO. This is still quite inconclusive but I will be testing tomorrow whole day so I still may come up with something.
beholder  
#64 Posted : Wednesday, September 4, 2019 4:34:29 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
So I eventually made it fail, same'ol'same sa before.

But then I did a change to the X1 and X2 scripts which might have fixed it. It's very primitive but it did the work I guess, because I've been trying to fk it for 25 minutes and nothing:
Code:
var ct = 0;
while(sp.GetStoredBool("XClick")) {
    sp.Sleep(10);
    ct++;
    if(ct > 100) break;
}

if(ct <= 100) {
    sp.StoreBool("XClick", true);
    var className = sp.WindowFromPoint(click.Point, true).RootWindow.ClassName;
    if(className && className == "OperaWindowClass"){
        //If Opera and button is down, send Page Down
        if(click.Down) {
            sp.SendKeys("{PgUp}");
        }
    } else {
        //If not Opera [and any XButton1 click event was detected], always send XButton1 click up
        sp.MouseClick(sp.GetCurrentMousePoint(), MouseButtons.XButton1, false, true);
    }
    sp.StoreBool("XClick", false);
}


The key change is the line: sp.MouseClick(sp.GetCurrentMousePoint(), MouseButtons.XButton1, false, true);

It is an unconditional unclicking of X1 copied directly from the FW script and it does not use the "click" object so it supposedly does not get mislead about how and where to click. The X1 button is intentionally being unclicked all the time when not in Opera. This SEEMS to work against the bug but I guess time will tell.. still testing, expect more definitive answer within 24 hours possibly. There seems to be less swapping, less mouse gestures being stuck in the middle, less mouse jerking in general. Weird.

Edited by user Wednesday, September 4, 2019 4:45:05 PM(UTC)  | Reason: Not specified

beholder  
#65 Posted : Monday, September 9, 2019 4:27:33 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
I've grown quiet lately, due to the fact there have been very little slowdown-related events on this computer. I am quite positive that S+ 0.341 also contributed to this, I have experienced exactly one such X1 or X2 mouse button related event during various testing and messing with X1 click script. Other than that it's been exceptionally stable. I have just installed the new-new 0.341 so I continue ocassionally trying to mess with it.

I have also edited the script above so that it doesn't send click to programs each time on Xbutton down and up (=twice) but only on up (=once). Seems quite stable although this modification was probably how I was able to trigger the buttons mismatch at least once, if I remember correctly. More testing is needed but I got quite fed up with running 4k videos and several script-heavy websites all at the same time and trying to invoke this chimera of a bug without success. It's chimera probably because the S+ program changes for better more than often enough.
beholder  
#66 Posted : Monday, September 9, 2019 10:20:28 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
Just had a small lock down of SOME mouse functionality. Interesting thing is that it was probably caused by RMB+wheel up in Opera. System was not taxed at all. I also don't remember using any other gesture / button at that time nor any other program. The RMB+wheel was not working so started checking it out.. Then realized that taskbar clicks were not responding. But Xbutton1 and Xbutton2 worked fine in Opera. I alt-tabbed to Windows Commander and found out the whole program was not responding, I mean it was completely locked, could not click it to see/move cursor or anything. I alt-tabbed back to Opera and tried RMB+wheel and this time it worked. Seemingly unlocked everything.

So I guess there might be another similar mechanism to locking of XMouse keys, this time related to RMB+mouse wheel. Could it be? Perhaps worth checking it out?
beholder  
#67 Posted : Tuesday, September 10, 2019 2:30:31 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

Groups: Approved
Joined: 8/9/2019(UTC)
Posts: 86
Slovakia

Thanks: 6 times
The start of the locking process usually looks like this:

During high system stress I click RMB. The RMB default action in a program happens (for example right-click menu shows) but the S+ blue trace also appears and seems to be stuck for about 1.5s. Note that I do not hold the RMB at all, I just clicked a short click in the beginning. After the blue stroke trace disappears, a mouse button is stuck, possibly my me pressing it (intentionally to make the bug happen). Last time this happened, it locked multiple functions and I could not unstuck it by alt-tabbing, had to use the trick with S+ Foreground Window script being on for a short while. In Opera it unlocked one of the MouseX buttons and from there on it worked normally. It unlocked it in Opera because the unlocking part of the FW script runs only in Opera.
Users browsing this topic
2 Pages<12
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.