Disable touch input with BlockInput

[tlman12]

I'm trying to run a script where I do not want the user to interact and potentially stop the process in the middle. not as worried about the ctrl+alt+del as i am of them clicking the window because one of the commands takes a while to run and windows marks the process as not responding allowing them to close it if they try enough times. 

the problem is we have surface pro devices that are primarily used in touch screen and it appears the the user is still allowed to interact with the screen even during a blockinput. I also tried the _BlockInputEX() and that still allows touch screen interaction. 

I only want to use something like devcon as to disable the screen as a last resort because if it doesn't re-enable for some reason it would be a decent pain in the @$$

any ideas?

[tlman12]

Bump

[MikahS]

all touch inputs are is mouse-clicks essentially. Are you blocking the mouse left and right buttons?

Edited August 28, 2014 by MikahS

[abberration]

I have read that on Vista/Win7/8 you must use #RequireAdmin for BlockInput to work correctly.

[MikahS]

If I'm not mistaken #RequireAdmin does not work on win 8, it's been so long I hope I'm wrong

[martin]

  On 8/28/2014 at 5:46 PM, MikahS said:

all touch inputs are is mouse-clicks essentially.

Definitely not the case.

Edited August 30, 2014 by martin

[tlman12]

  On 8/28/2014 at 5:46 PM, MikahS said:

all touch inputs are is mouse-clicks essentially. Are you blocking the mouse left and right buttons?

 

I am blocking right and left mouse buttons

 

  On 8/28/2014 at 8:51 PM, abberration said:

I have read that on Vista/Win7/8 you must use #RequireAdmin for BlockInput to work correctly.

 

I am using #RequireAdmin, and yes it does not work at all without it. 

 

  On 8/29/2014 at 6:01 PM, MikahS said:

If I'm not mistaken #RequireAdmin does not work on win 8, it's been so long I hope I'm wrong

 

#RequireAdmin is fully compatible (i'm using it on windows 8.1)

 

I wrote in some logging for the _BlockInputEx() include i found. 

i was logging this info

FileWriteLine(".\Mouse.txt",$nCode & "," & $wParam & "," & $lParam & "," & $MOUSEHOOKSTRUCT & "," & $iExtraInfo & "," & $iMouse_Event & "," & $iBlockAllInput)

and got this 

 

0,0x00000200,0x0139F598,,1,512,0

0,0x00000200,0x0139F598,,1,512,0

0,0x00000201,0x0139F598,,4294967295,513,0

0,0x00000202,0x0139F598,,4294967295,514,0

from what i could find out, $iMouse_event 512 is a mouse move, 513 is a left click down and 514 is a left click up

 

the $iExtraInfo is where it looses me, can't find any info about that but if i use a normal mouse click this information is 0, 

 

if i modify the function to run even if that info is a non 0 i bock most input but for some reason i am still allowed to open the charms bar, scroll through windows that were already open and highlight (not open) files on the desktop. so something is defiantly happening that isn't being picked up by a lowlevel mouse hook. 

 

this is the udf i'm using to block input 

 

it seems like i'd have to hook into some other message interface to grab the touchscreen interaction but it is not well documented at all 

[MikahS]

I use the mouse left button input for a tablet locker for software wanted from a consulting job awhile back. I mouse trap it into a button unto the user essentially clicks the button with his finger. Works like a charm. Good to see someone is on my butt though, thanks martin for clearing that up, as I will need to dive in and figure that out as well.

Glad to hear it is working perfectly on Win 8.1 tlman12