IsKeyDown(@SHIFT) issue

Started by Ron47, November 19, 2021, 01:34:06 PM

Previous topic - Next topic

Ron47

I use "IsKeyDown(@SHIFT)" in several of my scripts.
Pressing the shift key reliably closes the subroutine. The problem arises when I try to close a running subroutine from a second subroutine.
(I need to let the user have both options, both pressing the shift key or just running a second (unrelated) subroutine that first closes the running routine.)
I've tried variations of MousePlay( "", "", "", @shift, 1) to stop the subroutine.
Can't find one that's completely reliable.
I then found this alternative in the WinBatch tech database article: W14603.
dll = StrCat(DirWindows(1), "user32.dll")
DllCall(dll, void:"keybd_event", long:16, long:0, long:0, long:0); shift key down
Delay(3)
DllCall(dll, void:"keybd_event", long:16, long:0, long:2, long:0); shift key up

This works reliably but the shift key usually remains down. (If you click someplace on the screen, everything will be selected from the previous click.)
Adding sendkey("{esc}") to the above prevents the selection but only if you wait a few seconds before you click on the screen.
Any suggestions?
Thanks!
Ron

td

Seems a bit Rube Goldbergian to use keystrokes to terminate a subroutine. Since WinBatch does not run multi-threaded most of the time, you must either be calling one subroutine from the other or the subroutines must be executing in two separate instances of a WinBatch process. There are multiple ways to terminate a running WinBatch process from another running WinBatch process. Without knowing more about exactly how your subroutines are executing in relation to each other it is difficult to give specific advice.

Don't think it makes a difference in this case but keybd_event is a deprecated Win32 API. MSFT states that you should use SendInput instead and of course, it is a bit more involved to setup.

"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

Ron47

You're right.
(These are simple scripts that are not related to one another.)
I'll keep the "IsKeyDown(@SHIFT)" to let users cancel by keyboard and look into ways to terminate a running WinBatch process from another running WinBatch process.
Thanks!

jmburton2001

Quote from: td on November 19, 2021, 02:06:25 PM
Seems a bit Rube Goldbergian to...

I'll be the first to admit that sometimes I look at Golbergian setups and marvel at the elegance of their complexity.  ;D

Ron47

Using
if winexist("test")  then IntControl(47, "test", 0, 0, 0)
to close a script works but this solution has become its own Golbergian joke because there are quite a few scripts with different window names and then there are a couple of scripts where a simple shift key press just works better.
I have everything working but an updated keybd_event would still be welcome.



td

Sending keystrokes to perform any task should be used as a last resort because it will eventually bite you in the backside. This is because the console keyboard is a cross process shared device. With regard to an update to "keybd_event", there is nothing to update. If you are referring to "SendInput", there are examples in the Tech DB. Search on the function name.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

td

Quote from: jmburton2001 on November 20, 2021, 05:50:53 AM
Quote from: td on November 19, 2021, 02:06:25 PM
Seems a bit Rube Goldbergian to...

I'll be the first to admit that sometimes I look at Golbergian setups and marvel at the elegance of their complexity.  ;D

They are entertaining for sure. They have are their place but emulating their approach to problem solving in WIL scripts often leads to untoward outcomes.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade

Ron47

Thanks!
I have a simple alternative working...

jmburton2001

Quote from: td on November 21, 2021, 09:27:34 AMSending keystrokes to perform any task should be used as a last resort because it will eventually bite you in the backside.

Hahahaha... Blast from the past (mid to late 90s)! Our WAN was built on a 64k backbone (hence the TimeDelays) and this was the only thing we could get to work on our Cisco equipment!

Code (winbatch) Select
case 2 ; Telnet Password Change
RunZoom("telnet.exe", Addr)
SendKey(OldTN)
SendKey(`{ENTER}`)
TimeDelay(2)
SendKey("^D")
SendKey("P")
SendKey(`{UP}{ENTER}`)
TimeDelay(2)
SendKey(OldFA)
SendKey(`{ENTER}{ENTER}`)
SendKey(`{UP}{UP}{UP}{ENTER}`)
TimeDelay(2)
SendKey(`{UP}{ENTER}`)
SendKey(`{DOWN}{DOWN}{DOWN}{DOWN}{DOWN}`)
TimeDelay(1)
SendKey(`{DOWN}{DOWN}{DOWN}{DOWN}{DOWN}{ENTER}`)
SendKey(NewTN)
SendKey(`{ENTER}`)
SendKey(`{LEFT}`)
TimeDelay(2)
SendKey(`{2}`)
SendKey(`{LEFT}`)
TimeDelay(2)
SendKey("^D")
SendKey("C")
SendKey(`{ENTER}`)
TimeDelay(2)
SendKey("!{F4}")
goto start


Rube Goldberg would have been proud!

td

Looks like something you could generate using the newer version of WinMacro except that WinMacro uses SenKey's optional delay parameter.
"No one who sees a peregrine falcon fly can ever forget the beauty and thrill of that flight."
  - Dr. Tom Cade