AutoHotInterception - still sending original key function

Get help with using AutoHotkey (v1.1 and older) and its commands and hotkeys
Fisatec
Posts: 42
Joined: 26 Sep 2022, 07:31

AutoHotInterception - still sending original key function

Post by Fisatec » 31 Mar 2023, 04:46

Hi @all,

I got an external Numpad and would like to use just these keys to trigger some actions. The keys on my main keaboard shouldn't be affected.
For example I am trying to set up a script, which reloads my scripts that are always active from startup by pressing Numpad0.

It does kinda work, but sometimes the original key function (0) is also sent. I am using context mode. Mostly because I do not know the difference to subscription mode and I only got it working at times.

Code: Select all

#SingleInstance force
#Persistent
#include Lib\AutoHotInterception.ahk

AHI := new AutoHotInterception()
id1 := AHI.GetKeyboardId(0x1A2C, 0x2124)
cm1 := AHI.CreateContextManager(id1)
return

#if cm1.IsActive

Numpad0:: 
	Process, close, Sort.exe
	Process, close, Combined.exe	
	Process, close, ProCall.exe
	Process, close, Print.exe	
	
	Process, WaitClose, Print.exe	
	Run, %A_MyDocuments%\Sort.exe	
	Run, %A_MyDocuments%\Combined.exe
	Run, %A_MyDocuments%\ProCall.exe
	Run, %A_MyDocuments%\Print.exe
	return		
#if
In this case, my scripts will be closed and just run again by pressing Numpad0.
Most likely not the smartest way to do so :monkeysee:

Best regards
Fisatec

User avatar
mikeyww
Posts: 26856
Joined: 09 Sep 2014, 18:38

Re: AutoHotInterception - still sending original key function

Post by mikeyww » 31 Mar 2023, 05:23

Hello,

Although I have not used AutoHotInterception, I can offer a couple of ideas.

1. If your hotkey itself is being sent, it could mean that your #If condition is not met, even if momentarily. This may not make sense when you think of how the script is written-- you imagine that it is impossible for the Numpad0 to have been triggered elsewhere-- but it makes sense in terms of the logic of what the script itself is doing. If you imagine that you don't actually know what the included library does, then it is conceivable that the condition is sometimes not met. The easy part is that you can quickly modify the script to determine whether the condition is always met. For example, you can add a new hotkey, the same one, that uses the default context (no #If). You can then see if it is triggered. A general example is below.

Code: Select all

#Requires AutoHotkey v1.1.33
Numpad0::MsgBox NOT ACTIVE
#If isActive
Numpad0::MsgBox ACTIVE
#If
This is an approach to troubleshooting your script that will give you more information than you have now.

2. A string of Run commands can sometimes cause timing problems. I often put a short sleep (e.g., 200 ms) between them.

#Persistent has no effect, because all scripts with hotkeys are automatically persistent.

Fisatec
Posts: 42
Joined: 26 Sep 2022, 07:31

Re: AutoHotInterception - still sending original key function

Post by Fisatec » 31 Mar 2023, 07:52

@mikeyww Thank you very much for your post.

I tried like mentioned and it seems to be a random event.
NOT ACTIVE and ACTIVE show up randomly.

When I run my posted script with editor opened and I do spam Numpad0, then the "0" is send to editor several times.

Kind regards
Fisatec

User avatar
mikeyww
Posts: 26856
Joined: 09 Sep 2014, 18:38

Re: AutoHotInterception - still sending original key function

Post by mikeyww » 31 Mar 2023, 09:29

OK. I guess that means that cm1.IsActive is sometimes false when you were expecting it to be true. Perhaps the interception library is not detecting the device at all times, you are not using the library correctly, the device itself does not work properly or has unexpected behavior, etc. How to fix the issue is another matter. For some scripts, they need adjustments to timing, but I'm not sure that this would apply to your script. Some users of the AutoHotInterception library may have some focused tips for you here.

Fisatec
Posts: 42
Joined: 26 Sep 2022, 07:31

Re: AutoHotInterception - still sending original key function

Post by Fisatec » 03 Apr 2023, 01:02

At the weekend I just checked evilC/AutoHotInterception's GitHub and found an issue from 2019:
https://github.com/evilC/AutoHotInterception/issues/57

I changed my script from context mode to subscription and it seems to work properly now.
This is my current code:

Code: Select all

#SingleInstance force
#Persistent
#include Lib\AutoHotInterception.ahk

AHI := new AutoHotInterception()
id1 := AHI.GetKeyboardId(0x1A2C, 0x2124, 1)

AHI.SubscribeKey(id1, GetKeySC("Numpad0"), true, Func("Kb1Event"))
return

#if cm1.IsActive

Kb1Event(state){
	if (state){
		Process, close, Sort.exe
		Process, close, Combined.exe	
		Process, close, ProCall.exe
		Process, close, Print.exe	
		
		Process, WaitClose, Print.exe	
		Run, %A_MyDocuments%\Sort.exe	
		Sleep 100
		Run, %A_MyDocuments%\Combined.exe
		Sleep 100
		Run, %A_MyDocuments%\ProCall.exe
		Sleep 100
		Run, %A_MyDocuments%\Print.exe
	}
}

@mikeyww thanks for your support :)

Best regards
Fisatec

Post Reply

Return to “Ask for Help (v1)”