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

Notification

Icon
Error

2 Pages12>
Options
Go to last post Go to first unread
beholder  
#1 Posted : Saturday, August 17, 2019 5:09:02 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
I keep testing the new X1 and X2 buttons with my software and it goes quite well.. However recently I've been stopped by an unprecedented bug which may stem from how my system works with StrokesPlus.net (S+):

The system locks any RMB action when S+ is active. No right-click menu works, no gesture recognition works. Right-clicking on tray menu items does nothing. Even S+ doesn't show the tray menu on right button click. This all when S+ is active. Interestingly though, the X1 and X2 mouse button actions work perfectly when S+ is active. RMB gestures are drawn but don't activate any action.

When I turn off S+ by clearing it from system memory or when I deactivate it by LMB clicking on tray icon, right clicking starts working everywhere. Activating S+ back or reloading it turns the RMB off again.

When I replace the stroke button to MMB, the gestures still don't work with MMB -- but RMB starts working everywhere normally even when S+ is running and active.

I am sure that this is not a bug saved to a config. I tried to replace the config file by a default config file. Didn't remove the bug.

I restarted S+ multiple times, I even restarted explorer.exe. I disabled and restarted mouse driver. Nothing fixed it yet. No other app with hooks is in system memory.

I am quite positive a system restart would fix this problem. However, before I do that, is there anything I could do try to figure out what may have caused it?
Rob  
#2 Posted : Saturday, August 17, 2019 9:41:53 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
That is very odd, it's like the stroke button event is being consumed. There are very few things which would cause the event to be consumed, and the recent addition should not be affecting this in any way.

The fact that changing strokes buttons results in the other event being consumed would lead me to believe that somehow S+ is in fact intentionally consuming the event, but I can't think of why...especially with using the default config.

Can you try downloading the trace version and running it with mouse hook, core capture events checked and send me the log files?

https://forum.strokesplus.net/posts/t3012-Tracing-Logging-Builds-for-Troubleshooting
beholder  
#3 Posted : Sunday, August 18, 2019 5:21:45 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
That is very odd, it's like the stroke button event is being consumed. There are very few things which would cause the event to be consumed, and the recent addition should not be affecting this in any way.

The fact that changing strokes buttons results in the other event being consumed would lead me to believe that somehow S+ is in fact intentionally consuming the event, but I can't think of why...especially with using the default config.

Can you try downloading the trace version and running it with mouse hook, core capture events checked and send me the log files?

https://forum.strokesplus.net/posts/t3012-Tracing-Logging-Builds-for-Troubleshooting


Thank you for support.

In the meantime I have suspended the computer (hibernation) and when it got back out of sleep, S+ started working normally after I loaded it back. In the meantime I have also rerun old StrokesPlus and Event Ghost in tandem, then turned them off. Something got the system working correctly with hooks.

I will investigate this in the future, I have a feeling this system locking is when filesystem is working at peaks. There have been similar reports in old StrokesPlus forum in the past but nothing substantial came out of them. Event Ghost hangs in similar manner, restarting it usually helps. Old StrokesPlus gets strangely disabled (while still being enabled), normally disabling and enabling it makes it work after such a filesystem peak.
beholder  
#4 Posted : Sunday, August 18, 2019 5:25:28 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Ok, I got it resurfaced again. It's probably NOT related to filesystem peaks. It's related to the script I am working with in another thread, I will continue there so we can untangle this.
beholder  
#5 Posted : Friday, August 23, 2019 11:00:31 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Actually, it has reared its ugly head again! This time unrelated to anything known, I just clicked RMB after loading a web page. And RMB locked as before, when S+ is on, it is locked. EVEN AFTER I TURN S+ APPLICATION OFF AND ON AGAIN. Even if I upgrade S+ in the meantime.

So I quickly downloaded a trace build and made you a small log. All I do there is load S+, enable it (because I load it disabled), switch application, click RMB a few times, make a few gestures (they don't work), disable S+. Should be well readable.

Please check it out to see what might be going on with this machine, I believe it's not much of a S+ problem but it's currently the only app that locks RMB like this. So it might be.

Log here: https://drive.google.com/open?id=1kWs0R3Mb3XwhOJwuqahAdMjb7mTDojby

BTW, any way to make attachments in this forum? Would be handy.
Rob  
#6 Posted : Friday, August 23, 2019 11:44:00 AM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
When you say "RMB locked", what exactly do you mean?

Right-clicking doesn't work in the application if you just do a single right-click?

I think looking at the log, that's what you're experiencing.

These two lines seem to indicate the issue:
Code:
23. 8. 2019 18:50:12: MouseHook.cs::MouseProc(): DrawPointAssignments: MOUSE UP - DrawPoints.Count = 1
23. 8. 2019 18:50:12: MouseHook.cs::MouseProc(): CoreCaptureEvents: FIRE GESTURE


After the first line, the next one should really be:
Code:
CoreCaptureEvents: EMIT STROKE BUTTON CLICK


Unfortunately, it looks like my logging isn't showing the X1/X2 buttons, as it doesn't look like any other modifier is down:
Code:
23. 8. 2019 18:50:12: ApplicationMatching.cs::ActionMatched(): GestureName:  -  Secondary Stroke: False -  CtrlDown: False CtrlDownBef: False AltDown: False AltDownBef: False -  ShiftDown: False ShiftDownBef: False LeftDown: False LeftDownBefore: False MidDown: False MidDownBef: False -  RightDown: False RightDownBef: False WheelDown: False WheelUp: False


Instead, it thinks there was a modifier pressed, so it attempts to execute a matching action, which there is none, so it does nothing:
Code:
23. 8. 2019 18:50:12: [14] HookState.cs::FireGestureThread(): No Match - About to play sound
23. 8. 2019 18:50:12: [14] HookState.cs::FireGestureThread(): No Match - About to relay gesture
23. 8. 2019 18:50:12: [14] HookState.cs::FireGestureThread(): Exiting function


Here is the stripped down pseudo code of what's happening in that spot:
Code:
Log: "(): DrawPointAssignments: MOUSE UP - DrawPoints.Count = " + HookState.DrawPoints.Count.ToString());
if (HookState.DrawPoints.Count == 1
	&& HookState.MouseWheelUp == false 
	&& HookState.MouseWheelDown == false 
	&& HookState.LeftMouseDown == false 
	&& HookState.MiddleMouseDown == false 
	&& HookState.RightMouseDown == false 
	&& HookState.X1MouseDown == false 
	&& HookState.X2MouseDown == false
	&& HookState.ControlDown == false 
	&& HookState.AltDown == false 
	&& HookState.ShiftDown == false 
	&& HookState.LeftMouseDownBefore == false 
	&& HookState.MiddleMouseDownBefore == false 
	&& HookState.RightMouseDownBefore == false 
	&& HookState.X1MouseDownBefore == false 
	&& HookState.X2MouseDownBefore == false
	&& HookState.ControlDownBefore == false 
	&& HookState.AltDownBefore == false 
	&& HookState.ShiftDownBefore == false)
{
	if (wasSecondary)
	{
		Log: "(): CoreCaptureEvents: EMIT SECONDARY STROKE BUTTON CLICK");
	}
	else
	{
		Log: "(): CoreCaptureEvents: EMIT STROKE BUTTON CLICK"
	}
}
else
{
	Log: "(): CoreCaptureEvents: FIRE GESTURE");"
}


Your log shows 1 draw point, so that's right, but the modifier checks must not be passing (one must be true), so instead of emitting the stroke button, it's trying to fire a gesture.

I'd say press all keys (Control/Alt/Shift) a few times, then do the same for all mouse buttons, Right/Middle/Left/X1/X2.
Rob  
#7 Posted : Friday, August 23, 2019 11:50:53 AM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
You know, it's possible there is a certain race condition due to your X1/X2 consume settings.

I'm trying to think of the sequence of events, but somehow the X1 down (for example) is not consumed, but by the time you release, the window focus has changed and the up event is consumed due to the setting.

again, I can't yet put the sequence of events together, but it certainly seems the most plausible, other than a hardware issue.
beholder  
#8 Posted : Friday, August 23, 2019 12:49:25 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
When you say "RMB locked", what exactly do you mean?

Right-clicking doesn't work in the application if you just do a single right-click?


Yep, exactly. When S+ is enabled, no right click is registered in any application. Mouse strokes show blue trace, but are not executed.

Unable to unlock this "locked RMB" mouse state by clicking or pressing any modifier keys. Off the top of my head, maybe some kind of virtual key is being pressed?

Hmm, perhaps you could make a new trace build which shows which modifier is pressed?
beholder  
#9 Posted : Friday, August 23, 2019 1:18:57 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
btw, all X1 and X2 actions as well as Window Events are off. Still the bug is on.
Rob  
#10 Posted : Friday, August 23, 2019 1:34:19 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Uploaded 0.3.3.9 with an additional trace log entry, and added the other missing ones.

Manually download, enter version on download page.
beholder  
#11 Posted : Friday, August 23, 2019 1:37:31 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Thanks, I've got children to feed here but right after that I will send additional log.
Rob  
#12 Posted : Friday, August 23, 2019 2:02:58 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Okay. So here's what the output would look like.

Not blocking the RMB:
Code:
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - DrawPoints.Count = 1
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - LeftMouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - LeftMouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MiddleMouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MiddleMouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - RightMouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X1MouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X1MouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X2MouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X2MouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MouseWheelDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MouseWheelUp = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ControlDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ControlDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - AltDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - AltDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ShiftDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ShiftDownBefore = False
HookState.cs::MouseProc(): CoreCaptureEvents: EMIT STROKE BUTTON CLICK


Blocking the RMB/looking for an action to execute:
Code:
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - DrawPoints.Count = 1
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - LeftMouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - LeftMouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MiddleMouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MiddleMouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - RightMouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X1MouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X1MouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X2MouseDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X2MouseDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MouseWheelDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - MouseWheelUp = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ControlDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ControlDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - AltDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - AltDownBefore = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ShiftDown = False
MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - ShiftDownBefore = True
MouseHook.cs::MouseProc(): CoreCaptureEvents: FIRE GESTURE

(note the ShiftDownBefore = True)
beholder  
#13 Posted : Friday, August 23, 2019 2:32:52 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Hmm, just after I wrote last msg the bug "unbugged" itself. Seems like "the modifier key" got unstucked somehow. I did some testing now and the locked system looks like JUST LIKE as if ALT key was pressed down. Try it on your system: hold ALT and try to click RMB. No other modifier key does this. This is how it feels when the bug is on.

I will try to get the system into the RMB-locked state, I think it will happen today or tomorrow for sure. I have the new trace build already installed so now it's just a question of time.
beholder  
#14 Posted : Saturday, August 24, 2019 9:22:10 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
I think I caught it, and THIS TIME ALSO BEING ACTIVATED.

Here are two logs, one is long dirty log which has the bug being activated somewhere at the end. At the end I switch programs and try to click RMB. The last action should be deactivating S+.

Another log is very clean, where I just activate S+ and in the BUG-ON state I then do a few RMB clicks, S+ strokes and deactivate.

Both logs and all future logs are here:
https://drive.google.com/open?id=1KS04d1usQmWkp45PDvJLXCA2QgNlzegR


I also remember my system getting to semi-locked mouse clicks state just as this bug went active. No clicks are accepted in this state but it can be broken by CTRL+ALT+DEL and running task manager. A moment later the clicks are accepted. My system sometimes does that, not sure what it is. But it may not be related to the S+ problem at all..





Rob  
#15 Posted : Saturday, August 24, 2019 10:27:00 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Code:
25. 8. 2019 5:12:58: MouseHook.cs::MouseProc(): CoreCaptureEvents: MOUSE UP - X1MouseDownBefore = True


So yeah, the X1 button was in the down state at the time the RMB was pressed. So it thinks you're trying to execute a X1+RMB action and absorbs the RMB.

To confirm this, make a global action with no gesture, X1 modifier, capture modifiers Before and this script would be executed.

Now as to the reason X1 is down, this is the issue. I see the window foreground script is being executed, so again the possibility exists of a race condition (not consuming the down event, but consuming the up leaving the mouse stuck in the down state), meaning the cause is related to S+, but not a bug just a need to enhance the script to better avoid the race condition.

Or there's another process interfering somewhere, leaving the X1 down in someway, a combination of S+ and another program getting in each other's way, a mouse driver issue, or a hardware problem.

I'll have to review the longer log file in more detail to see when it started happening.
beholder  
#16 Posted : Sunday, August 25, 2019 10:27:50 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
hmm, I don't use RMB+X1 combo at all. I use just individual X1 and X2 buttons and only in special case when I am working with Opera. There is no reason for me to press RMB+X1 at the same time, especially in other programs.
Rob  
#17 Posted : Sunday, August 25, 2019 12:17:00 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
I'm not saying you do, just saying what S+ is seeing.

So imagine you have your foreground window script turned on. Every single time a window gains focus, which happens a LOT, the foreground window script is executed.

Let's say you have Notepad open and focused, so X1 would not have clicks consumed by S+ (because of the foreground window script).

You have Opera visible, next to Notepad.

While Notepad is still the active window, you move the mouse over Opera and click the X1 button.

The X1 button down event is NOT absorbed by S+, because the setting still says to not consume the X1 button.

However, once the foreground window changes to Opera (well before you've released the X1 button), the foreground window script executes and since Opera is now the foreground window, it changes the setting to consume X1 click events.

Note that this all happens very quickly.

Between the time you pressed the X1 button down and released the X1 button at least 100 milliseconds have probably passed.

Now that S+ is consuming X1 click events, it absorbs the release (up) of the X1 button. So now Windows still believes, and treats, the X1 button as being held down even if it is no longer physically being pressed down. That's the way low level hooks, like S+ uses, work.

Now usually, if you just press the X1 down and release it, this would reset the state of the button within Windows.

But if S+ is still consuming X1 click events, it will not.

Hopefully this makes sense.

I'm not saying this is definitively what happened, just one possibility.

It's also possible that that the mouse has a hardware problem with the actual X1 switch where it gets stuck in the engaged position.

Edited by user Sunday, August 25, 2019 12:21:50 PM(UTC)  | Reason: Not specified

Rob  
#18 Posted : Sunday, August 25, 2019 4:21:13 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
I released an updated 0.3.3.9 for everyone, which includes those extra checks in the cancel timer functions.

Also added sp.TraceLogEntry("message here") function which will let you directly add a line to the trace log, for anywhere it's useful. Of course, a script has to be executing in some way to actually add it to. This function only works in the trace build. It won't cause a script error in the non-trace build, it just doesn't do anything at all.

I also put this together, which is an updated version of the Foreground Window script. It uses the trace log function and checks to see if the X1 or X2 buttons are down when starting to consume X1/X2 clicks, so it would reset the X1/X2 buttons back to released/up.
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); 
    }
    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); 
    }
}
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, September 2, 2019 6:50:24 PM(UTC)  | Reason: Not specified

beholder  
#19 Posted : Sunday, August 25, 2019 5:19:26 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Thanks. I installed immediately as I found out. I also added a little balloon tip to the script to notify me if it goes bonkers the way you think, because if it does fix the failed state by itself, I have no way to find out unless I search the log periodically.
beholder  
#20 Posted : Tuesday, August 27, 2019 4:56:40 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
I think we caught this one really well. I do get occasional slow downs when doing several things at once, most notably when executing gestures with videos playing in Chrome. But I never encountered a locked state anymore.

It does lock itself for a very small time (like 1-3 secs) but it's usually self-recovered (with no script warnings, so I guess the Window Events script may not even execute). Or it is recoverable by pressing the mouse buttons one by one several times after the slow down is over. I wonder if S+ doesn't contribute to the slow downs itself: the mouse starts jerking for about 1-2 seconds and it's very difficult to do any gesture. Then it goes away by itself.

Furthermore I now occasionally get this, I noticed that it usually does that when I try to close a window with video playing starting a close gesture on the video itself:

Script execution failed; Error: Object reference not set to an instance of an object at script document [47]:2:4 ->sp.sendKeys("^w")

Looks like one of those bugs when S+ loses a reference to an object like before? Perhaps you could check out in the sources based on this report or I can try to log it again..
beholder  
#21 Posted : Tuesday, August 27, 2019 5:14:59 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Forgot to add that the 1-3s mouse jerking starts after pressing RMB. Interesting huh? I also occasionally get the "No script engine available" message. Is there any way to have "more engines" available?
beholder  
#22 Posted : Tuesday, August 27, 2019 5:30:10 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Now I was consistently getting unresponsive S+ with following msg:

Script execution failed.

Error: The best overloaded method match for 'StrokesPlus.net.Engine.ActionFunctions.MouseClick(System.Drawing.Point, string, bool, bool)' has some invalid arguments at Script Document [77]:12:12 -> sp.MouseClick(sp.GetCurrent.MouseCursor(),MouseButtons.XButton1,false,true);

I mean always when I switch to Opera 12, it then defocuses Opera 12 and shows the msg. Then I can click Opera again and get the msg again, etc. RMB unresponsive. Restart didn't help so I was at some stuck button again.

After restarting S+ when I pressed Xbutton1 or Xbutton2 I got: Script Execution failed. The V8 runtime cannot perform the requested operation because a script exception is pending.
(probably meant the exception message earlier which was not easy to send away)

Then I closed all of the exception messages and switched by keyboard to a different application. Then unstucked the X1 and X2 buttons. Then everything worked normally.
Rob  
#23 Posted : Wednesday, August 28, 2019 7:46:41 AM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Code:
sp.MouseClick(sp.GetCurrent.MouseCursor(),MouseButtons.XButton1,false,true);


There shouldn't be a "." between GetCurrent and MouseCursor.

Regarding the slowdown/jerking, you might try running without the gesture drawing (line) enabled (Options > General > Draw Gesture), just for a bit to see if the jerking stops. That has to blend the transparency of the drawing surface with all other windows. Playing a video would require more intensive alpha blending. It sounds like your system may not be very powerful (primarily GPU for the blending, anyway) or is frequently taxed in terms of available resources.

I have absolutely no idea how sp.SendKeys could result in object reference error, there aren't any object instances involved. It uses .SendWait which is a static method, so there's no instance of the SendKeys class. Is there anything else in this script that could be the cause? Is this in a try/catch?

Regarding script engines, Options > Advances > Use Script Engine Pool - Max Script Pool Size - Just note that each script engine takes a certain amount of memory, so don't make it too high.

The downside of the Foreground Window script is that it ends up executing a lot, which may be the source of a few of these issues.

Edited by user Wednesday, August 28, 2019 7:58:25 AM(UTC)  | Reason: Not specified

beholder  
#24 Posted : Wednesday, August 28, 2019 8:56:24 AM(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
Code:
sp.MouseClick(sp.GetCurrent.MouseCursor(),MouseButtons.XButton1,false,true);


There shouldn't be a "." between GetCurrent and MouseCursor.


Understood, this was just a mistake on my part when I rewrote the error msg to the forum. It's interesting that this part of the FW script was processed while it didn't show my balloon tips. I have now modified the tips to be simpler, maybe there was an issue with showing them. I am now quite sure this branch did run but I'll see fore sure tonight.

Originally Posted by: Rob Go to Quoted Post
Regarding the slowdown/jerking, you might try running without the gesture drawing (line) enabled (Options > General > Draw Gesture), just for a bit to see if the jerking stops. That has to blend the transparency of the drawing surface with all other windows. Playing a video would require more intensive alpha blending. It sounds like your system may not be very powerful (primarily GPU for the blending, anyway) or is frequently taxed in terms of available resources.

I have absolutely no idea how sp.SendKeys could result in object reference error, there aren't any object instances involved. It uses .SendWait which is a static method, so there's no instance of the SendKeys class. Is there anything else in this script that could be the cause? Is this in a try/catch?


No try/catch, nothing else in this script. It's just a simple keystroke invocation of Ctrl+W.

Originally Posted by: Rob Go to Quoted Post
Regarding script engines, Options > Advances > Use Script Engine Pool - Max Script Pool Size - Just note that each script engine takes a certain amount of memory, so don't make it too high.

The downside of the Foreground Window script is that it ends up executing a lot, which may be the source of a few of these issues.


Just upped the script pool to 4, we will see what it'll do.
Rob  
#25 Posted : Wednesday, August 28, 2019 12:35:15 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Oh yeah I forgot to mention this as well.

So back in 0.2.9.3 I was testing an alternative drawing method, so instead of the drawing happening within the mouse hook itself, which could lag the mouse responsiveness if the drawing surface is lagging, I have a hidden option to use a method which instead posts a message to the surface form for it to handle the drawing outside of the mouse hook's processing.

I haven't really tested it much and I don't think people are using it. Might be worth seeing if it resolves any mouse jerking.

Code:
sp_config.UseAlternativeDrawingMethod = true;
sp_config.Save();
sp.MessageBox("sp_config.UseAlternativeDrawingMethod is now:\n" + sp_config.UseAlternativeDrawingMethod, "Drawing Method");


You can just change the first line to "= false;" to set things back to the default method.

You can also try checking Options > Advanced > Draw Surface Always on Top - Just note that some apps might behave oddly if they think an application is above them (they shouldn't do this since the window is transparent and no focus, but I can't control how they write their code).
Rob  
#26 Posted : Wednesday, August 28, 2019 1:14:19 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Basically a hook works like this:

1. You click/move the mouse
2. Windows sends the event to the S+ hook
3. If S+ returns 1, then it's like the event never occurred
4. Otherwise S+ returns the result of CallNextHook which passes the event along to any other hooks
5. If another program has a mouse hook, it has to follow the same rules as 3 & 4 above
6. If no hook returns 1, the event happens in Windows (visible by you/applications)

So during the RMB and start to draw a gesture, S+ is bringing the gesture drawing surface window to the foreground, which performs transparency blending, then gets a device context, and draws a line segment.
If there are delays during this time, the mouse events are held up waiting for these things to complete before the hook can continue processing and let Windows know whether or not the event should happen.

This alternate method instead posts a message to the drawing surface window so the hook/event continues processing very quickly, meaning it shouldn't cause the mouse to lag while it's waiting for the drawing surface to get ready and paint.
Rob  
#27 Posted : Wednesday, August 28, 2019 1:17:37 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
I'm now running with this option enabled so I can see if I run into any problems with it.
beholder  
#28 Posted : Wednesday, August 28, 2019 3:27:11 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
Code:
sp_config.UseAlternativeDrawingMethod = true;
sp_config.Save();
sp.MessageBox("sp_config.UseAlternativeDrawingMethod is now:\n" + sp_config.UseAlternativeDrawingMethod, "Drawing Method");


So how do I run this script properly? I mean just once, in the beginning of S+.net startup? I tried both Hotkeys and Macros for running it once but when I ran another macro/hotkey script which just checked and displayed the config value, it was always false.

Rob  
#29 Posted : Wednesday, August 28, 2019 4:36:24 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Just execute it once. However, make sure the Settings window is closed before you do, since the config is copied into the Settings window when it's opened, and that is used to update the settings when you click okay or cancel.

It's complicated, but when the Settings window is open, that config seen by the script engine is volatile, meaning any changes will not persist.

After you've executed it once without the Settings window, you wouldn't have to execute it again. Depending on how my and your testing go, I'll bring it into a checkbox in the Options > Advanced area.
beholder  
#30 Posted : Wednesday, August 28, 2019 5:29:06 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
So I activated it properly (thanks) and nothing much changed during the limited testing I've done in a few minutes. Will continue testing to see any possible changes.

One thing seems to be a little off, but this might have been there before only I didn't notice it that much.. I get these unclickable areas of the screen (or maybe of a specific program). Currently I am often getting the top 1/4 screen unclickable. Had to go to Task Manager from CTRL+ALT+Del screen to make it clickable. So I was wondering if there is a possibility this might have been caused by some forgotten overlay hanging there after S+ forgot it there by being very stressed by the system. Please note that I push this system to extremes to test this stuff, this is not my usual mode of operation and the system with the latest S+ is quite stable.
Rob  
#31 Posted : Wednesday, August 28, 2019 6:00:01 PM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
What's interesting that I forgot about until now is that in your trace logs I saw some entries about the mouse being outside of the screen area. Shouldn't usually cause an issue, but if you were in the middle of a gesture, I'm not sure how it would handle that. Of course what I'm wondering is how the mouse went outside of the screen area...very interesting.

Do you have multiple monitors? If so, are they at different resolutions or DPI scaling? That can always be challenging to troubleshoot and handle perfectly as well.

The gesture draw window covers whole virtual desktop, so I'm not sure how only an area would become unclickable, not to say it couldn't happen, just not sure how it would just yet.

I'm glad to hear that it is normally stable, lol. From the posts, it feels like it's just a mess and problems all of the time!
beholder  
#32 Posted : Wednesday, August 28, 2019 6:38:17 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Oh, believe me, it's gotten much more stable and mature after the last 2 weeks. Your software is on the brink of what I would pay for with real money and that's something to say :-D
I am convinced that once we're done with these issues the software WILL FLY on modern computers.

No multiple monitors, just one. Scaling is at 125% though. I turned it off but it will take time for me to restart the machine, too much work is open.

The "off screen area" must be some kind of bug in the display or mouse drivers (but I am using generic mouse drivers with a pretty much generic mouse so I guess it's more of a display driver problem). Theoretically it MIGHT go off-screen in the jerking movement when I move the mouse too much. The system is stressed and this might happen, although I have no idea how it's possible. The problem must be some kind of chipset or display driver related bottleneck because the mouse jerking is ALWAYS accompanied by heavy disk usage AND heavy disk/system usage USUALLY brings about the jerking problems.

I still have to test multiple aspects of this, like running without S+ and trying to do stuff to see the jerking or if mouse generally works, etc.

One think occured to me, a crazy idea. Turn off the S+.net stroke overlay but still use it for gestures. Then turn on strokesplus (not the .net) to display the overlay and show the gestures but not do the actual actions, i.e. do nothing.

This obviously didn't work, believe me I tried, but my next thought in this line of thinking was: what if you split the S+.net into a gesture display agent (an exe file) and an actual hooking agent (another exe file). So one would just dutifuly display the stuff, the other would have it configured and would simply execute strokes without being hindered. I know, it sounds like a lot of work but let's just think aloud whether this could be relevant to the actual speed and efficiency of current S+.net. Chrome does something like this, btw.

Rob  
#33 Posted : Thursday, August 29, 2019 5:19:01 AM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
The mouse off screen might also be fast movements to the right or bottom edge before the message is processed and Windows puts the mouse back inside the desktop area. There are software KVM style apps that might allow for off screen positions to show on other PCs, etc so it may be perfectly fine.

Heh, no...running S+ and S+.net together would not work well since they're both hooking the mouse. But the alternative drawing method (in theory) should be more like the situation you're describing. Instead of the mouse hook processing the gesture drawing, its posted to the main loop for it to do the drawing instead of the hook code. Doing some research and I think the main app thread is still the one handling the hook calls based on the docs, so the hook and gesture drawing might still be in contention, but in a different way. Moving the hook code to its own thread would probably be the best way to eliminate that, but that will likely be a bit complicated (more threads = more possible race conditions!). I will still take a look into it and see how it looks.

Rob  
#34 Posted : Thursday, August 29, 2019 6:51:28 AM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Well so far it seems that creating a new window/thread to handle the mouse hook and message pump was pretty easy (no changes to any core code, just around starting/stopping the mouse hook) and doesn't seem to cause any problems.

Try manually downloading 0.3.4.0 and running it with the alternative drawing method still enabled. If this is stable for us for a while, I'll release with alternative method on by default (deprecating/removing the option) and using the new hook thread.

Obviously we'll want to test all of the pathways/options, but I've hit the major ones and haven't experienced any issues.

So now all mouse events are invoked in the context of a separate thread which does nothing but handle mouse hook messages. The drawing is handled by the main thread which the mouse hook posts a message to.



beholder  
#35 Posted : Thursday, August 29, 2019 10:19:50 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Thanks, just downloaded and installed. Results will be within hours.
Rob  
#36 Posted : Friday, August 30, 2019 6:35:14 AM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Updated the 0.3.4.0 download, nothing major just some code optimizations in the mouse hook and application matching code (slightly more efficient).
beholder  
#37 Posted : Friday, August 30, 2019 6:59:08 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
awesome. Installing right away.

In the meantime I have taken some stress off the system, gave it more disk space, bigger virtual memory fixed size file, updated sound driver, etc. So I will be now testing in more realistic conditions. I believe I still can stress the system enough for mouse weirdness to appear. It's got something with disk access to swap file, I am sure of it, many people have this Windows issue. I am tempted to buy a small fast USB 3.0 memory and use it for virtual memory exclusively -- if I ever get tired of it eventually.

FYI, I am getting a weird small S+ message when restarting Windows 7, "frmMouseHook closing", always just as system is shutting down. Restarted couple of times and this came up always. It prevents a quick system shut down because Windows is always waiting for it to close.
Rob  
#38 Posted : Friday, August 30, 2019 8:26:45 AM(UTC)
Rob

Rank: Administration

Reputation:

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

Thanks: 5 times
Was thanked: 78 time(s) in 68 post(s)
Haha, oops I left that in there, used it for testing things.

Uploaded an update for 0.3.4.0 which removes that, it also includes a new announcements feature (you won't see anything yet), but essentially if update check is enabled, it will also check for any important announcements and display them.

Just an FYI in case anything odd related to that shows up, as I've only tested it a little bit so far this morning after adding the code.
beholder  
#39 Posted : Friday, August 30, 2019 9:22:15 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Thanks, installed. Results possibly tonight.
beholder  
#40 Posted : Friday, August 30, 2019 2:20:04 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Here, I got this perplexing error along with mouse anomalies on this somewhat faster system now:
https://drive.google.com/open?id=1d7ygNSVsCtkfe9gTGSGCipN2Q0c6SyUg
Users browsing this topic
2 Pages12>
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.