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 : Tuesday, August 20, 2019 1:23:55 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
I have discovered that the ^v keystroke/action does not work properly when I use it on the content of the Find Dialog in the Notepad++. It's kind of difficult to reproduce this without installing Notepad++ so please bear with me.
  1. Install Notepad++
  2. enter random text into the N++ window.
  3. copy a word of the random text by selecting it with mouse and using ctrl+c on keyboard
  4. go to different line of random text with cursor
  5. press ctrl+f on keyboard to show Search Dialog
  6. execute the ctrl+v gesture with S+

What is expected:
  • the text in search dialog window should be replaced with the text from clipboard


What happens:
  • the text in search dialog is not replaced, instead the main window text may be replaced or appended to


Possibly related:
Ctrl+c gesture seems to be doing the same wrong thing and does not work sometimes in the Search Dialog but I have a difficult time reproducing it reliably. It certainly does something wrong sometimes (does not copy text to clipboard) but at other times it does the right thing.

Somewhat unrelated, I have discovered this throws some kind of exception:
Code:
sp.SendControlDown();
sp.SendVKey(vk.c);
sp.SendControlUp();


BTW, is there any way to copy text from these error notices? I can't find any and it looks like screenshots are the only way to go here. It would be much easier if their text would be selectable and copyable.
Rob  
#2 Posted : Tuesday, August 20, 2019 2:24:11 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Uncheck Options > General > Always Activate Window Where Gesture Began

With the original S+, I did not have that kind of functionality automatically enabled, because I wanted each user to decide what happens. But SO MANY people complained, that I made it a default option.

So it's activating (setting as foreground) the root window when drawing a gesture, which is the main window, not the popup/Find window.

I can't win! No matter what I do to try to make things satisfy people, there are always exceptions! :)

Note that you can enable Before Action Scripts to conditionally handle this, if you are so inclined.

Edited by user Tuesday, August 20, 2019 3:31:09 AM(UTC)  | Reason: Not specified

Rob  
#3 Posted : Tuesday, August 20, 2019 2:25:26 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Re: Control Down / V / Control Up...do you have any additional details?
Rob  
#4 Posted : Tuesday, August 20, 2019 2:29:37 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Also, JavaScript does support try/catch, but I'm not 100% sure if it would capture the error message from the system or not, but in theory it should.

e.g.

Code:
try {
    throw "this is an error";
} catch (err) {
    sp.MessageBox(err, "Error");
}


Of course, you don't need to throw an error yourself, just wrap the calling code and clip.SetText(err) in the catch.
Rob  
#5 Posted : Tuesday, August 20, 2019 2:33:11 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Oh wait, you need:

Code:
sp.SendControlDown();
sp.SendVKey(vk.VK_C);
sp.SendControlUp();


Autocomplete is your friend :)

But still, try/catch can be very useful.
thanks 1 user thanked Rob for this useful post.
beholder on 8/20/2019(UTC)
Rob  
#6 Posted : Tuesday, August 20, 2019 2:43:05 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Also (I'm a little drunk right now..), you can enable script debugging to step through scripts in Chrome...See here https://forum.strokesplus.net/posts/t5028-Debugging-Scripts

But to properly catch a host exception (error originating from S+, not a JavaScript exception) within a try catch, this would put the error message on the clipboard:

Code:
try {
    sp.SendControlDown();
    sp.SendVKey(vk.c);
    sp.SendControlUp();
} catch (err) {
    debugger;
    clip.SetText(err.hostException.Message);
    sp.MessageBox(err.hostException.Message, "Error");
}


The debugger; line was my trying to find the correct property of the error message in Chrome Dev Tools.

Of course, the error "The best overloaded method match for 'StrokesPlus.net.Engine.ActionFunctions.SendVKey(WindowsInput.Native.VirtualKeyCode)' has some invalid arguments" means that the arguments (vk.c) is invalid, because it's not a valid value of the vk object.

Edited by user Tuesday, August 20, 2019 3:32:06 AM(UTC)  | Reason: Not specified

thanks 1 user thanked Rob for this useful post.
beholder on 8/20/2019(UTC)
Rob  
#7 Posted : Tuesday, August 20, 2019 1:49:53 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Oh also, in 0.3.3.5 I made some changes to how window activation works. It should behave more as expected instead of focusing the main window.
beholder  
#8 Posted : Tuesday, August 20, 2019 5:26:23 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Originally Posted by: Rob Go to Quoted Post
Oh also, in 0.3.3.5 I made some changes to how window activation works. It should behave more as expected instead of focusing the main window.


OMG, this fixed it! Thanks! SystemWindow.FirstMoveableParent FTW!

Just possibly one related issue though, no need to fix immediately:
- not sure if it's related but the Script Help loses focus when Mouse Wheel Relaying is on and user scrolls the wheel over it. Quite weird. Not sure where actually the focus goes then.

Unrelated Script Help issues:
- FirstMoveableParent description in Script Help has last line cut off if the Script Help window height is default (1200p display here); I can make the window bigger to rectify but isn't a scrollbar missing on the right in this case?
- unable to select/copy text from Script Help
- unable to change font size in Script Help to make the text more readable for tired eyes
- unable to search in Script Help?




beholder  
#9 Posted : Tuesday, August 20, 2019 5:33:31 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Originally Posted by: beholder Go to Quoted Post

- unable to select/copy text from Script Help
When selecting/copying from Name/Type/Description fields.

Rob  
#10 Posted : Tuesday, August 20, 2019 7:34:47 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Yeah, that Script Help window was just jammed together quickly, I need to go back to it and refine things.

I spent days putting all of the attributes and help text together and was just done with it! Once it just barely worked enough to be minimally acceptable, I called it good at the time.
beholder  
#11 Posted : Wednesday, August 21, 2019 12:38:48 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Originally Posted by: beholder Go to Quoted Post
- not sure if it's related but the Script Help loses focus when Mouse Wheel Relaying is on and user scrolls the wheel over it. Quite weird. Not sure where actually the focus goes then.

update: this issue went away when I turned off the Activate Window Under Mouse Wheel. Quite counter-intuitively, checking this option DEACTIVATES the active foreground windows of Script Help and/or StrokesPlus.net under mouse wheel scrolling.

Or possibly I just don't get it somehow again..

beholder  
#12 Posted : Wednesday, August 21, 2019 12:52:29 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Originally Posted by: beholder Go to Quoted Post
Originally Posted by: beholder Go to Quoted Post
- not sure if it's related but the Script Help loses focus when Mouse Wheel Relaying is on and user scrolls the wheel over it. Quite weird. Not sure where actually the focus goes then.

update: this issue went away when I turned off the Activate Window Under Mouse Wheel. Quite counter-intuitively, checking this option DEACTIVATES the active foreground windows of Script Help and/or StrokesPlus.net under mouse wheel scrolling.

Or possibly I just don't get it somehow again..

update2: forgot to note earlier that this seems to also be an issue in both Notepad++ and Opera 12 subwindows such as search (N++) or bookmark page (O12, when trying to scroll a long list of existing bookmark directories, this issue directly prevents me from scrolling them by wheel). Please note that Mouse Wheel Relaying must also be turn on.

Again, quite counter-intuitively, turning off the "Activate Window Under Mouse Wheel" fixes this behavior.
Rob  
#13 Posted : Wednesday, August 21, 2019 1:34:59 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
I'll have a look at those tomorrow. To be honest, since Windows 8 or maybe 10 the relay mouse wheel is no longer necessary so I haven't revisited those code sections in a while.
Rob  
#14 Posted : Wednesday, August 21, 2019 2:43:46 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Heh, I had a bad coordinate trying to get the window, instead of getting the window @ X,Y, I was using Y,Y which would explain the very odd behavior :)

I also changed that activation to use the FirstMoveableParent.

I released this fix, though it is not yet referenced on the site. This is because I've been tinkering with creating a WPF form for the Script Help window to make it much more user friendly, but that requires bringing in the WPF references and I'm not yet sure if that will cause any issues. Since you're on Win 7, you're the perfect test person!

So go here https://www.strokesplus.net/Downloads and scroll down to the bottom, enter 0.3.3.6 and click the installer or portable button to download this version.

Let me know if it works fine for you, then I'll publish it for everyone else.
beholder  
#15 Posted : Wednesday, August 21, 2019 5:09:50 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Testing went well so far, didn't have much time but I put it on and redid the few testcases:

No more weird focus switching. Everything seems to be fine now except the reported behavior of selects. You click a select, try to scroll the [many] possibilities and the select immediately closes (selects the last entry that was already selected). Both Relay Mouse Events and Activate Window Under Wheel must be on for this behavior.

This goes exactly like described above for latest Notepad++, so it should be easy to work out what's wrong there. Unable to wheel-scroll large selects there. Opera 12 gives a mixed result now, when I scroll above the clicked selector itself, it works as expected (first click it, then roll wheel directly above where you clicked). But when I click it and then move mouse cursor down to the rolette where all of the options are and where scrolling actually happens, upon scrolling it immediately selects an arbitrary value as if I clicked one of the options.

So I say fk old Opera now and let's focus on N++. How to test:
  1. make sure both Relay Mouse Events and Activate Window Under Wheel are on in S+
  2. load N++
  3. go to Settings>preferences>General
  4. click the Localization select
  5. scroll mouse over it
Rob  
#16 Posted : Wednesday, August 21, 2019 6:42:28 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
This stuff is always such a pain to get just right :)

Okay, I made some changes again so it only activates if the root owner window handle is not the same as the root owner window handle for the control below the mouse cursor...AND only if the root owner window hwnd is NOT the Desktop window (which list dropdown popups are owned by the Desktop....you know, just because it's fun that way..

Oh, I also reorganized a bunch of code into the common project, so again, you get to be my tester to make sure things work right :)

Let me know if things work right in general, and about the mouse wheel stuff.

I just overwrote the previous download, so same version, follow the same steps as my previous post to download version 0.3.3.6.
beholder  
#17 Posted : Wednesday, August 21, 2019 9:15:03 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Sure, thanks. Will get to testing right away. Funnily enough, I dont even normally use the Activate Window Under Wheel, we both do this out of pure perfectionism and for others.
beholder  
#18 Posted : Wednesday, August 21, 2019 10:48:32 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
The new 0.3.3.6 looks a bit better, Notepad++ seems without any problems whatsoever. However browsers like Opera 12 and newest Chrome still show abnormalities in select behavior. After clicking a select both disable active selecting when mouse wheel is used.

For Opera 12 you can click menu Tools>Appearance and on tab Themes use the Icon Size select to test (click & scroll).

For Chrome, go to chrome://settings/ and try to scroll any select that you clicked there.

Needless to say, both Relay Mouse Events and Activate Window Under Wheel must be on for this behavior. I also keep testing the other modes (with Activate Window Under Wheel off) so I will report more anomalies if I find any. Just wanted to let you know right away that N++ seems to be fine now and others are not yet.
beholder  
#19 Posted : Wednesday, August 21, 2019 10:57:12 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
edit: For Chrome, go to chrome://settings/ and try to click any select & scroll over its OPTIONS below it.
Rob  
#20 Posted : Wednesday, August 21, 2019 11:35:41 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Yeah, Chrome is yet another difference. I don't have Opera installed.

So it looks like it creates its own window to own the popup, the handle changes each time you open the list, so it's only purpose is to host the menu/receive messages I'm guessing, kind of like TrackPopupMenuEx.

That makes it a bit more challenging. Since there's no window relationship from the popup window to the foreground window (Chrome Settings window, for example), other than by process, that I can find anyway.

So I could just say don't activate if it's the same process ID...but then, if you have 2 Chrome windows open side by side, it wouldn't activate the other if you were over it (even though chrome.exe has a dozen processes running in Task Manager, only one seems to be for the UI). It's a bit of a mess to handle this perfectly...still trying to think about how it could be done.

By the way, this is a script I use to help with finding out window details, you might find it handy.

IMPORTANT: It's setup to stop once the mouse Y position is >= 1070. So change that accordingly.

Code:
var currpt = sp.GetCurrentMousePoint();
var info = new DisplayTextInfo();
info.Message = "";
info.MessageAlignment = "left";
info.Duration = 1000;
info.Location = (currpt.X-30)+','+(currpt.Y+20); 
info.MessageFont = new Font("Segoe UI Semibold", 12);
info.BackColor = "black";
info.Padding = 0;
info.ClipToWorkingArea = false;
sp.DisplayText(info);
while (currpt.Y < 1070) {
    currpt = sp.GetCurrentMousePoint();
    wnd = sp.WindowFromPoint(currpt, false);
    var fgWindow = sp.ForegroundWindow();
    info.Title = wnd.Title;
    info.Message = "\nMouse Location: x: "+currpt.X+" y: " + currpt.Y
    info.Message += "\nDesktop Window HWnd: " + sp.DesktopWindow().HWnd.ToString();
    info.Message += "\nForegroundWindow HWnd: " + fgWindow.HWnd.ToString();
    info.Message += "\nForegroundWindow Class: " + fgWindow.ClassName;
    info.Message += "\nForegroundWindow Title: " + fgWindow.Title;
    try {
        info.Message += "\nForegroundWindow Process ID: " + fgWindow.Process.Id;
        info.Message += "\nForegroundWindow Process Name: " + fgWindow.Process.MainModule.ModuleName;
    } catch {}
    info.Message += "\nForegroundWindow.GetRootOwnerWindow HWnd: " + fgWindow.GetRootOwnerWindow.HWnd.ToString();
    info.Message += "\nForegroundWindow.GetRootOwnerWindow Class: " + fgWindow.GetRootOwnerWindow.ClassName;
    info.Message += "\nForegroundWindow.GetRootOwnerWindow Title: " + fgWindow.GetRootOwnerWindow.Title;
    info.Message += "\nCursor Window HWnd: " + host.cast(nint,wnd.HWnd) 
    info.Message += "\nCursor Window Class: "+wnd.ClassName
    info.Message += "\nCursor Window Title: "+wnd.Title
    try {
        info.Message += "\nCursor Window Process ID: "+wnd.Process.Id;
        info.Message += "\nCursor Window Process Name: "+wnd.Process.MainModule.ModuleName;
    } catch {}
    var extra = "";
    try
    {
        extra = "\nCursor Window.Parent HWnd: " + wnd.Parent.HWnd.ToString();        
        extra += "\nCursor Window.Parent Class: " + wnd.Parent.ClassName;
        extra += "\nCursor Window.Parent Title: " + wnd.Parent.Title;
        extra += "\nCursor GetRootOwnerWindow HWnd: " + wnd.GetRootOwnerWindow.HWnd.ToString();
        extra += "\nCursor GetRootOwnerWindow Class: " + wnd.GetRootOwnerWindow.ClassName;
        extra += "\nCursor GetRootOwnerWindow Title: " + wnd.GetRootOwnerWindow.Title;
    }
    catch{}
    info.Message += extra;
    info.Location = (currpt.X-30)+','+(currpt.Y+20); 
    sp.DisplayTextUpdate(info);
    sp.Sleep(25);
}


By the way, since it's working (the rest of the program) and the coordinate fix was definitely a bug that needed to be fixed, I went ahead an published this. I mean, it's definitely better than it was, just not 100% perfect and will continue to think about a way to handle this if it's possible.

Edited by user Thursday, August 22, 2019 1:04:00 PM(UTC)  | Reason: Not specified

thanks 1 user thanked Rob for this useful post.
beholder on 8/22/2019(UTC)
beholder  
#21 Posted : Sunday, September 1, 2019 6:54:34 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
The S+ software is now pretty stable and work with it is quite manageable even on slowed-down system. The XButton1 and XButton2 notices are also finally working (the Foreground Window fix in the other thread fixed it).

I am however still plagued by those occasional transparent windows in front of all open windows, which disable RMB or LMB clicking (actually LMB sometimes seems to get through the transparency sometimes). So I have bound the above window identifying script to a keystroke in hope to catch the transparent window info, hopefully it will work. More info when I eventually get it tonight.

As for the latest incident (I still haven't had the Window Identifier script ready), I pressed all of the modifier keys until I got to Left Windows button which somehow unstuck the transparent window.Then immediately my Foreground Window balloon notice showed by itself about X1 button being unstuck also. And all was working. I am writing this more as as bug log for myself so I don't forget how it all happened.
beholder  
#22 Posted : Monday, September 2, 2019 1:36:30 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Alas, this window identifying script probably does not see any transparent overlays.. I did some testing with old strokesplus and it could not see it, from what I glimpsed (because the new S+.net hijacked the yellow gesture in under 1/2 sec). It also cannot identify its own transparent overlay. So I guess my quest to identify what is leaving the overlay ON after stressed system activity is probably over. My suspicion is that it's S+ but it's difficult to say, more testing is needed.
Rob  
#23 Posted : Monday, September 2, 2019 2:36:01 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Yeah it can be difficult to identify transparent and no activate windows.

I use Spy++ for these types of things or when I want to see every message a window receives.

When this happens, are you able to click anywhere, or does it affect the entire screen(s)?
beholder  
#24 Posted : Monday, September 2, 2019 11:49:28 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Left clicks might or might not be working (it's difficult to get system to this state so I am not sure, will write more detailed report when it happens) but right clicks never work. Gestures are drawn but not executed, even global gestures. Seems like a combination of a transparent window on top of others and a stuck key. Recently I have noticed that when I alt+tab to another program and back, all starts working.
beholder  
#25 Posted : Monday, September 2, 2019 11:53:03 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
I have downloaded winspy to quickly figure out what window it is. So now it will be a question of time, if this thing works on transparent windows.
Rob  
#26 Posted : Monday, September 2, 2019 1:00:38 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
I uploaded version 0.3.4.1 which has a couple code checks and logic which might handle this...? Not sure, since I can't reproduce the issue.

I basically added two events to the gesture surface form:
- Click
- Activated

If either of those events occur, it calls the existing code to deactivate the drawing surface (hide or send to bottom of stack, depending on options) then re-enable the window if keep gesture window on top is enabled.

In theory, they never should occur but I think it must be happening somewhere under certain conditions/timing, especially since alt+tabbing to another window resolves the issue as that would deactivate the surface window and get things back to normal.

If the Activated event somehow doesn't catch it, then click should really be the last line of defense. If this happens, the first click would behave like you're experiencing, but that calls the deactivation code and (in theory) the next click would work fine. This would be a good confirmation that the surface window has become active, though it will be harder to notice since the first click should resolve, so it's easy to think you maybe just didn't click the mouse right or missed where you were clicking. While not ideal (the click event), it's the best option which doesn't involve some kind of timer code constantly checking things. If the activate event isn't catching it due to system resource contention/timing, the click is a user driven event which is repeatable and people always click...and more than once if things aren't responding right away!

Of course, I'll still also continue to think about other ways to optimize this to try to prevent it 100% of the time. But if this version resolves the issue, that is solid confirmation of the problem.
Rob  
#27 Posted : Monday, September 2, 2019 1:22:13 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Also make a hotkey with this script. If neither of the events seem to work and you can't click, press the hotkey and try again. If you're able to click again, then we'll know the surface was the issue and the events didn't resolve the window state issue.
Code:
sp.WindowFromClassOrTitle("", "StrokesPlus.net Gesture Surface").SendToBottom();
beholder  
#28 Posted : Monday, September 2, 2019 5:18:46 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
oooh, great. This will be handy. I have not installed the new version since I want to try this with the send to bottom, to confirm it.
beholder  
#29 Posted : Monday, September 2, 2019 6:03:23 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
so it happened again (or more or less I intentionally made it happen) and this time no clicks RMB, LMB were responding. No keystrokes worked, probably because this is a stuck overlay AND also stuck modifier. No gestures worked either. When I alt-tabbed to another program (from Chrome), the Foreground Window faithfully responded with notification bubble about unstucking a mouseX key and everything worked.

So next time I will be trying to unstuck it before actual alt-tab. Still didn't install the new version since I am trying to figure this out, slowly but persistently.
beholder  
#30 Posted : Monday, September 2, 2019 6:08:14 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
and how about a trace log, would it be helpful in this case? Shouldn't I use a trace buid?
beholder  
#31 Posted : Monday, September 2, 2019 6:39:45 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
This time left click works in the foreground program but RMB does not. Drawing gestures works but actions are not executed. Wheel works. Wheel gestures don't work. LMB clicking inside a program window works but clicking outside does not (like an overlay over tray, program tabs, quick launch, start button). S+ hotkeys don't work.

Left Windows key completely unstuck this state by showing the Windows start menu. Again a balloon msg showed about stuck X1 or X2, but I remember well that I tried them "to unstuck" them physically. Previously I was only able to unstuck this state by Ctrl+Alt+Del and clicking Task Manager.
Rob  
#32 Posted : Monday, September 2, 2019 7:07:31 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Yeah, you can use the trace version, see if it is able to show something to help figure this out.

Use these trace options:
  • ApplicationMatchingGeneralEvents
  • CoreCaptureEvents
  • DisableEnableEvents
  • DrawPointAssignments
  • frmSurfaceGeneralEvents
  • HookTimerEvents
  • HookStateGeneralEvents
  • ServerStateGeneralEvents
  • MouseHookGeneralEventsServerStateGeneralEvents
  • WinEventHookGeneralEvents

Installer:
https://www.strokesplus.net/files/StrokesPlus.net_Setup_0.3.4.1_Trace.exe

Portable:
https://www.strokesplus.net/files/StrokesPlus.net_Portable_0.3.4.1_Trace.zip
beholder  
#33 Posted : Monday, September 2, 2019 10:14:54 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Hey, here is the screen lockup log from 0.3.4.0 (whole screen, RMB + LMB lockup) with the recommended options, I have used an older version so we can catch this bastard faster. Next, as of right now I am running the trace version 0.3.4.1 so we will see how far it will fare.

In the end of the lockup I alt+tabbed to Windows Commander, you can clearly see it in the log. S+ fixed the lockup there.

The log SCREEN LOCKUP is in this logs dir:
https://drive.google.com/open?id=1KS04d1usQmWkp45PDvJLXCA2QgNlzegR
beholder  
#34 Posted : Monday, September 2, 2019 10:19:46 PM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
oh, forgot to add I got a script error in medias res but I saved the screen shot only to cache and then another cache content erased it, sorry. Something with PgUp action (my X1 or X2 action) not working.
Rob  
#35 Posted : Monday, September 2, 2019 10:46:53 PM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Re: Error, that's the same one as earlier, needs to use sp.GetCurrentMousePoint(), not sp.GetCurrentMouseCursor().

Will review the logs.
Rob  
#36 Posted : Tuesday, September 3, 2019 12:30:02 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
Okay, so looking through the logs, it looks like you were in Chrome. There was a gesture you executed [Back (backspace)] during which X1DownBefore == false (X1 not stuck down).
Then you clicked the left button a few times and at some point that led to Opera becoming active, which fired the foreground window change script.
Then you clicked X1 (down and up) very soon after clicking the left button which activated Opera. Well actually, you clicked X1 a few times, then X2 (maybe that's when you got the error message?).

The next RMB event then shows X1DownBefore = true (so it's now stuck in the down position).

So it seems that it is definitely related to the X1 script.

The only thing I can think of is that the sequence of X1 events happened in reverse, so you clicked down/up and the up event script fired first, followed by the X1 down script, leaving the button considered in the held down state. In the log, you see both threads firing one right after the other (but I don't know which one is which).

These click scripts are fired on threads, so the script doesn't have to complete execution before the mouse hook can respond to Windows about whether or not the S+ hook is going to consume the mouse event.

Under optimal conditions, the threads would generally end up executing in sequence, however there's no default guarantee in multi-threading that this will be the case. But if the system is having a CPU spike at the moment, it's quite possible that the two threads' execution doesn't happen sequentially (because there's no rule that they have to).

One of the many ways to address this is by using locks. A lock is an object that only one thread at a time can obtain, any other threads wanting to enter the code inside the lock have to wait until no other threads have locked the object, then it can obtain the lock and execute.

I've updated the 0.3.4.1 download to utilize some locks to hopefully prevent this (assuming this is what's happening). However, this still does not guarantee the threads are executed in sequence, but will generally be FIFO. I'd have to spend some time to re-architect the code in a way which guarantees fairness/sequence.

Fortunately for this case, we're not dealing with dozens of threads firing all the time; the threads are originated by human actions which are slow relative to computing speed.

Hopefully this will be sufficient enough to prevent this issue, again if this is the issue! However, I'm nearly 100% sure it relates to the X1 click scripts, and once the X1 button is stuck down, that can cause all sorts of odd behaviors.



I have one lock for all mouse click events, which lock around the creation of the script thread. Inside the script thread, I have 5 locks, one for each mouse button.

beholder  
#37 Posted : Tuesday, September 3, 2019 12:51:16 AM(UTC)
beholder

Rank: Advanced Member

Reputation:

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

Thanks: 6 times
Wonderful! It's been already quite difficult to get any anomalies from the previous version -- I even feel like one time I did that 1 redundant click you wrote about. Nevertheless I will fire up this version and test for just a short while (before I have to GTF off the computer) to see how it may possibly improve the things.. Results in minutes possibly.
Rob  
#38 Posted : Tuesday, September 3, 2019 12:54:12 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
heh, actually thinking through all of this again, you're not doing anything with the X1 button inside your X1 click script, it's only in the foreground window change script that it's referenced. I also thought of some other things which need further investigation.

I mean, the locks are probably a good idea anyway, though :)
Rob  
#39 Posted : Tuesday, September 3, 2019 1:01:01 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
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?
Rob  
#40 Posted : Tuesday, September 3, 2019 1:15:36 AM(UTC)
Rob

Rank: Administration

Reputation:

Groups: Translators, Members, Administrators
Joined: 1/11/2018(UTC)
Posts: 1,349
United States
Location: Tampa, FL

Thanks: 28 times
Was thanked: 416 time(s) in 354 post(s)
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.
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.