Author |
Topic |
|
Hypernova
18 Posts |
Posted - 02/04/2015 : 17:16:32
|
I've noticed this for a while now but I was hoping it will just go away as Windows 10 mature. Apparently not, so I guess I should report.
What I noticed is that StrokePlus seems to cause the pointer and the program that received the right click to be locked up for a period of time. Note the gesture line get drawn and I keep the right click down until timeout then the problem do not seem to occur.
One workaround I found is to set "Cancel Delay" option to 0 ms. Unfortunately, StrokePlus seems to always reset it back to 50 ms upon restart. |
|
Hypernova
18 Posts |
Posted - 02/10/2015 : 17:45:57
|
After spending roughly an hour trying to figure out a workaround without success, I better sum up what I found:
This issue is somehow related to the Modern apps in Windows 10. The lockup only occur when there is a non-minimized Modern app running and I right-click somewhere. If modern apps are minimized, no lockup will happen. Note that gestures themselves work fine on Modern apps. |
|
|
Rob
USA
2615 Posts |
Posted - 04/14/2015 : 10:01:38
|
I'll dig into this once the RC for Win10 is released. |
|
|
Hypernova
18 Posts |
Posted - 04/16/2015 : 16:08:25
|
Sounds great! Looking forward to it. If it is any help, Strokeit has no problem with Windows 10, including modern apps (beside appearing on taskbar). |
|
|
Rob
USA
2615 Posts |
Posted - 04/16/2015 : 17:59:26
|
Yea, I added late binding calls to IsImmersiveProcess, etc. that I know Strokeit didn't update to include. FWIW, though, I did install a VM with Win10 CTP and I don't experience the issue you described...so we'll see what happens. Especially since I'll be upgrading to Win10 on my dev machine, making it much more practical to code and debug against. |
|
|
Mertsch
9 Posts |
Posted - 04/30/2015 : 11:22:56
|
Hey, I can confirm the issue with the following observations * It happens in 2.8.2.0 and 2.8.3.2 with Windows 10 build 10074
* It happens ONLY on right click! If I start to draw a gesture (right button down) everything is as fluent as I know it from Windows 7, no matter if immersive process or normal desktop application. BUT if I right CLICK, there is roughly a 500ms - 1000ms time where the computer seems to be 100% busy. It is very well observable if you just right click the desktop and the context menu animation will be very jagged. Additionally there is barely any mouse movement possible.
Would be really awesome if you could have a look into that |
|
|
Rob
USA
2615 Posts |
Posted - 04/30/2015 : 11:28:58
|
When Windows 8 was in RC status, the S+ draw window would show on the Taskbar even though all of the properties were set properly. Once Windows went RTM, it was fixed without me doing anything. So, that's my reasoning for waiting to troubleshoot the issue. I intend to upgrade to Windows 10, do I've no doubt I'll resolve the issue. |
|
|
Mertsch
9 Posts |
Posted - 04/30/2015 : 11:41:06
|
I know what you mean :) This is what happens when you get so dependent on something. I just installed Windows >7 for the first time and when I was setting up everything I saw myself constantly doing gestures for window management and then telling myself ... argh you don't have S+ running, yet |
|
|
freakpaul
4 Posts |
Posted - 05/31/2015 : 13:16:10
|
hey, same issue for me, right clickling causes to freeze it for a short period of time. Did somebody maybe found a fix? :) |
|
|
nuance
5 Posts |
Posted - 07/13/2015 : 20:26:21
|
you are right.modern app window would cause gestures to perform with delay. I use 2.8.3.3 |
|
|
Rob
USA
2615 Posts |
Posted - 07/14/2015 : 09:16:40
|
As I mentioned previously, I would like to wait for the final release version. Also, when I installed CTP, I couldn't reproduce the problem. Would you all mind providing me with any specific details you can think of? For example, someone mentioned only when there are no minimized modern apps. Does it do it in full screen modern apps? Only when they're windowed? Only certain apps, all? Anything that I can use to narrow down the issue. I'm downloading the insider preview Win10 and will install. But running in a VM may be different than running native, so I'm not sure if it will reveal anything new.
Once I get the actual Win10 upgrade, I'll be able to identify the root of the issue...hopefully! |
|
|
Rob
USA
2615 Posts |
Posted - 07/15/2015 : 07:42:27
|
Well, good news and bad news. The good news is that I am able to see what it is you're all talking about. The bad news is, there doesn't appear to be anything I can do in the code that yields any results thus far. My best guess is that when modern apps are in view, Windows possibly overlays a touch input type of layer to the screen or to the processing of synthesized input. I've tried a dozen different ways of making the calls necessary to relay the right-click, but none of them have a single impact. Once there are no modern apps in view, things work as you'd expect.
The lag appears between the draw window state and sending the click; there's nothing between the code that isn't a WinAPI call...its: ShowWindow (or SetWindowPos, depending on preferences), then SendInput (for the click). No S+ code is doing anything between these calls, so I'm left scratching my head...something that Windows does/handles when modern apps are visible is the problem, but I can't find anything referencing what is different when I search.
I'll keep hacking away at it, I threw together a Win10 VM last night, but didn't install Visual Studio to get Spy++ etc.; maybe there's another full screen transparent window Windows brings up when modern apps are visible. The alpha blending between 2 fullscreen blended windows could be causing lag...not sure what is going on yet. |
|
|
Rob
USA
2615 Posts |
Posted - 07/15/2015 : 14:09:19
|
Try the updated version 2.8.4...let me know how/if it works. |
|
|
Hypernova
18 Posts |
Posted - 07/15/2015 : 15:10:47
|
Unfortunately still the same problem for me. Build 10166. Please let me know if you need to see the preference settings. |
|
|
Rob
USA
2615 Posts |
Posted - 07/15/2015 : 16:00:56
|
Well, it fixes it within a VirtualBox VM (for me, anyway)! =P Once I get Win10 retail on my actual machine, I'll be better able to track it down. |
|
|
nuance
5 Posts |
Posted - 07/19/2015 : 03:46:58
|
I installed 2.804.0 in windows 10 build10240,the problem still exists. |
|
|
Rob
USA
2615 Posts |
Posted - 07/19/2015 : 12:07:39
|
Yea, I don't know what's going on with Windows 10. The code is no different when there's a modern app visible or not. Yet, when a modern app is visible, there's just something else happening behind scenes...some layer of input hook...or something.
Of course, I'm still only running inside a VM, so I may not be seeing exactly what you're seeing. Would anyone mind uploading a video to YouTube showing the behavior to make sure what I'm seeing is the same? |
|
|
Rob
USA
2615 Posts |
Posted - 07/21/2015 : 18:18:07
|
It's like there's some hook that's going on...or something. So here's at least one thing that I've noticed, which is clearly not behaving as it should (watching Windows messages going to a File Explorer window, with S+ running and enabled):No modern app visible
WM_RBUTTONDOWN
WM_RBUTTONUP
Modern app visible
WM_RBUTTONUP
WM_RBUTTONDOWN
WM_RBUTTONUP Note here that there is absolutely nothing which is processed nor handled any differently by S+, yet something is injecting (or acting before the S+ hook has a chance to process) that first WM_RBUTTONUP. I know it's not S+ because I've added stuff in the dwExtraInfo parameter and it is not in the message for the first WM_RBUTTONUP message.
The WM_RBUTTONDOWN & WM_RBUTTONUP are injected by S+ when a right-click and release are performed and no modifiers or movement was detected...just relay along a full right-click. But when a modern app is visible, something else is acting and causing things to get messed up. In my VM, it doesn't cause a lock up/freeze, but the response is slower (for the popup menu) and sometimes, for example, in File Explorer I will get a full context menu when right-clicking on a file, and other times I get a right-click where there's no file selected. Normally, the WM_RBUTTONDOWN triggers the selection of the file, but with this mix of mouse messages, it doesn't behave consistently.
I still have no idea what's going on and I can't seem to find any windows or hooks evident that should be interfering, but it's definitely something within Windows as the S+ code is doing the exact same thing regardless of the visibility of a modern app. I've even changed the code to not overlay the gesture draw window, leaving it as a 0x0 rect without transparent properties, but it behaves the same. I'm really at a loss and hoping this is something MS either knows about or is going to address by the time retail is delivered. |
|
|
Hypernova
18 Posts |
Posted - 07/21/2015 : 18:36:06
|
Hi Rob. I'm pretty sure that when I tested again right after upgrading to build 10240 (with 2.8.4.0), the lock up still happened. But when I tried StrokePlus again just now (still 10240/2.8.4.0, but with the all updates from Windows Update), the lockup is very brief. It sounds like the same thing you see in your VM.
Just some quick thoughts. Can you/did you try the similar watching of WinMsg but with StrokeIt instead? Like I mentioned earlier, StrokeIt have no problem at all. Also, maybe you can try report to Microsoft? |
|
|
Rob
USA
2615 Posts |
Posted - 07/25/2015 : 00:00:12
|
Okay, try 2.8.4.1. |
|
|
Erebus
3 Posts |
Posted - 07/25/2015 : 04:18:26
|
2.8.4.1 Mouse spring by right click to left side. |
|
|
Hypernova
18 Posts |
Posted - 07/25/2015 : 05:44:38
|
2.8.4.1: Much better, but there are still delay sometimes. I think mostly when right click a non-focus windows |
|
|
nuance
5 Posts |
Posted - 07/25/2015 : 05:52:34
|
2.8.4.1 some(only a few) of the right click respond quickly. |
|
|
Rob
USA
2615 Posts |
Posted - 07/25/2015 : 09:28:00
|
Try 2.8.4.2...
Removed the mouse move part of the SendInput call to hopefully fix Erebus' issue. Also moved two other calls into the new function. I am unable to reproduce the issue anymore, though, so it may have to wait until I have Win10 on my dev machine.
Any info about when there's a delay would be helpful. |
|
|
Rob
USA
2615 Posts |
Posted - 07/25/2015 : 09:34:09
|
No, now I can see it again, the delay sometimes. Ugh, this makes no sense! |
|
|
Rob
USA
2615 Posts |
Posted - 07/25/2015 : 10:10:04
|
Ok, let's try unhooking and rehooking the mouse during the injected click
2.8.4.3 |
|
|
nuance
5 Posts |
Posted - 07/26/2015 : 02:32:28
|
in 2.8.4.3, it seems everything works fine.there is no delay at all. ps: the download link was wrong. |
|
|
Erebus
3 Posts |
Posted - 07/26/2015 : 03:24:35
|
2.8.4.3 works. |
|
|
Hypernova
18 Posts |
Posted - 07/26/2015 : 09:04:09
|
2.8.4.3 seems to be golden for me too. |
|
|
Rob
USA
2615 Posts |
Posted - 07/26/2015 : 13:23:30
|
Awesome! Thanks everyone. |
|
|
freakpaul
4 Posts |
Posted - 07/28/2015 : 12:23:43
|
Seems to work. I patiently waited for it. Excellent work rob! |
|
|
plunt
Italy
88 Posts |
Posted - 08/01/2019 : 12:00:12
|
[quote]No modern app visible
WM_RBUTTONDOWN
WM_RBUTTONUP
Modern app visible
WM_RBUTTONUP
WM_RBUTTONDOWN
WM_RBUTTONUP
I have a similar problem with SendInput, can I ask you how you solved it? |
|
|
Rob
USA
2615 Posts |
Posted - 08/01/2019 : 16:24:32
|
In the case of S+, I had to unhook the mouse while I was sending the right-click, then re-install the mouse hook. |
|
|
plunt
Italy
88 Posts |
Posted - 08/04/2019 : 04:11:31
|
ty |
|
|
|
Topic |
|