StrokesPlus Forum
                       
StrokesPlus Forum
Home | Profile | Register | Active Topics
Members | Search | FAQ
 All Forums
 Bug and Issues
 Resolved Bugs and Issues
 [RESOLVED] Windows 10 locked up when right click

Note: You must be registered in order to post a reply.
To register, click here. Registration is FREE!

UserName:
Password:
Format Mode:
Format: BoldItalicizedUnderlineStrikethrough Align LeftCenteredAlign Right Horizontal Rule Insert HyperlinkInsert EmailInsert Image Insert CodeInsert QuoteInsert List
   
Message:

* HTML is OFF
* Forum Code is ON
Smilies
Smile [:)] Big Smile [:D] Cool [8D] Blush [:I]
Tongue [:P] Evil [):] Wink [;)] Clown [:o)]
Black Eye [B)] Eight Ball [8] Frown [:(] Shy [8)]
Shocked [:0] Angry [:(!] Dead [xx(] Sleepy [|)]
Kisses [:X] Approve [^] Disapprove [V] Question [?]

 
Check here to subscribe to this topic.
   

T O P I C    R E V I E W
Hypernova 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.
33   L A T E S T    R E P L I E S    (Newest First)
plunt Posted - 08/04/2019 : 04:11:31
ty
Rob 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 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?
freakpaul Posted - 07/28/2015 : 12:23:43
Seems to work. I patiently waited for it. Excellent work rob!
Rob Posted - 07/26/2015 : 13:23:30
Awesome! Thanks everyone.
Hypernova Posted - 07/26/2015 : 09:04:09
2.8.4.3 seems to be golden for me too.
Erebus Posted - 07/26/2015 : 03:24:35
2.8.4.3 works.
nuance 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.
Rob Posted - 07/25/2015 : 10:10:04
Ok, let's try unhooking and rehooking the mouse during the injected click

2.8.4.3
Rob Posted - 07/25/2015 : 09:34:09
No, now I can see it again, the delay sometimes. Ugh, this makes no sense!
Rob 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.
nuance Posted - 07/25/2015 : 05:52:34
2.8.4.1
some(only a few) of the right click respond quickly.
Hypernova 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
Erebus Posted - 07/25/2015 : 04:18:26
2.8.4.1
Mouse spring by right click to left side.
Rob Posted - 07/25/2015 : 00:00:12
Okay, try 2.8.4.1.
Hypernova 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 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.
Rob 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?
nuance Posted - 07/19/2015 : 03:46:58
I installed 2.804.0 in windows 10 build10240,the problem still exists.
Rob 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.
Hypernova 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 Posted - 07/15/2015 : 14:09:19
Try the updated version 2.8.4...let me know how/if it works.
Rob 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 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!
nuance 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
freakpaul 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? :)
Mertsch 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
Rob 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 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 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.
Hypernova 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 Posted - 04/14/2015 : 10:01:38
I'll dig into this once the RC for Win10 is released.
Hypernova 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.

StrokesPlus Forum © 2011-2018 Rob Yapchanyk Go To Top Of Page
Snitz Forums 2000