Disable Warnings for currently unset keys

Get help with using AutoHotkey (v1.1 and older) and its commands and hotkeys
User avatar
Micromegas
Posts: 260
Joined: 28 Apr 2015, 23:02
Location: Germany

Disable Warnings for currently unset keys

21 Nov 2017, 12:52

My script defines some hotkeys that don't exist in all keyboard layouts, such as:

Code: Select all

^ö::Send Hello world!
On compilation, this causes warnings like
Note: The hotkey ^ö will not be active because it does not exist in the current keyboard layout.
How can this be turned off? #Warn has no option for that.
User avatar
Exaskryz
Posts: 2882
Joined: 17 Oct 2015, 20:28

Re: Disable Warnings for currently unset keys

21 Nov 2017, 15:01

What you might be able to do is define your hotkeys with the Hotkey command, conditionally with If statements.

Edit: I forgot to mention the GetKeyVK() function returned 0 for me because I didn't have a ö key, but returned 79 for me with the o key. That's why I am using the If statements like that.

Code: Select all

If GetKeyVK("ö")
Hotkey, ^ö, LabelA
If GetKeyVK("o")
Hotkey, ^o, LabelB
return

LabelA:
MsgBox Activated ö.
return

LabelB:
MsgBox Activated o.
return
This works for me to use the plain ^o hotkey. I do not have any special keys in my keyboard layout, so I could not trigger ^ö.

However, I am not warned about ö not existing in my keyboard layout with the code above, where as doing a regular hotkey like you used in the original post does trigger that error for me.

It may matter: I do run Unicode AHK (32 bit) and saved my the script above as UTF-8 without BOM encoding.
Last edited by Exaskryz on 21 Nov 2017, 18:04, edited 1 time in total.
A_AhkUser
Posts: 1147
Joined: 06 Mar 2017, 16:18
Location: France
Contact:

Re: Disable Warnings for currently unset keys

21 Nov 2017, 16:28

I didn't know the GetKeyVK function; never saw it before - interesting. According to the documentation this one can retrieve "(...) the name/text, virtual key code or scan code of a key.". Yet, according to what stated in the key list, one might be able to use those scan code when defining a double-colon label.

Code: Select all

sc10::MsgBox ;  sc10 is a
I wonder if the warning still appear defining a double-colon label hotkey using such a scan code.

Hotkey command as also an UseErrorLevel option (https://www.autohotkey.com/docs/command ... ErrorLevel) so that the code below may be able to achieve this too:

Code: Select all

Hotkey, ^ö, test, On UseErrorLevel
; if (ErrorLevel <> 2) ; ErrorLevel is set to 2 if "The KeyName parameter specifies one or more keys that are either not recognized or not supported by the current keyboard layout/language."
	; MsgBox, 16,, ERROR
return

test:
MsgBox % A_ThisLabel
return
my scripts
User avatar
Micromegas
Posts: 260
Joined: 28 Apr 2015, 23:02
Location: Germany

Re: Disable Warnings for currently unset keys

21 Nov 2017, 20:33

Thank you, guys. I understand that there seems to be no way to disable the warning, and your answers show several workarounds, so we can close this thread.

I think the most straightforward workaround is to use the scan code, as A_AhkUser suggested. Initially, I had reservations about that because I didn't want to affect the behavior when the keyboard is set to en-US, but I played around with it and it doesn't seem to negatively affect that locale, other than maybe a little performance hit. And in reply to your question, A_AhkUser, that makes the warnings go away.

However, I'm experiencing some strange behavior in other locales, which I posted as a new thread Remapped hotkeys behave strange in other locales.
User avatar
Micromegas
Posts: 260
Joined: 28 Apr 2015, 23:02
Location: Germany

Re: Disable Warnings for currently unset keys

23 Nov 2017, 08:33

Since I'm not able to resolve the issues listed in the new thread Remapped hotkeys behave strange in other locales, I can't use A_AhkUser's approach and am looking at Exaskryz's now. Unfortunately, that is more cumbersome in my case because I am not actually consuming the control keys myself, but sending them to whatever application may use them. The prime example is ^z, which is consumed by many applications. If it were just that, I could still use Send. But I also need to allow for key combinations. It seems to me, Exaskryz's, approach would need a label for every possible key combination, which is too cumbersome.
A_AhkUser
Posts: 1147
Joined: 06 Mar 2017, 16:18
Location: France
Contact:

Re: Disable Warnings for currently unset keys

05 Dec 2017, 17:52

Actually, create a label for any existing variant is not unavoidable. According to the documentation - in many case at least - a remapping is internally translated into a pair of hotkeys with their respective subroutines. Maybe this will be sufficient for what your are trying to achieve to convert these subroutines into functions, using a single variable reference containing a boundfunc object as label parameter of the hotkey command:

Code: Select all

SetKeyDelay -1
remaps := {base:{__Get:Func("default_get")}
		, o:{destinationKey:"z", onDown:Func("callback_Down"), onUp:Func("callback_Up")}
		, ö:{destinationKey:"z"}}

for variant, object in remaps {

	If GetKeyVK(variant) {
		f := Func("fDown").bind(object.destinationKey, object.onDown)
		Hotkey, % "*" . variant, % f
		f := Func("fUp").bind(object.destinationKey, object.onUp)
		Hotkey, % "*" . variant . " Up", % f
	}
	
}
return

fDown(__destinationKey, __onDown) {
Send {Blind}{%__destinationKey% DownTemp}
__onDown.call()
}

fUp(__destinationKey, __onUp) {
Send {Blind}{%__destinationKey% Up}
__onUp.call()
}
callback_Down() {
ToolTip % A_ThisFunc . A_Space . A_ThisHotkey
}
callback_Up() {
ToolTip % A_ThisFunc . A_Space . A_ThisHotkey
}

default_get() {
return Func("dummy")
}
dummy() {
return true
}
Last edited by A_AhkUser on 07 Dec 2017, 13:38, edited 1 time in total.
my scripts
User avatar
Micromegas
Posts: 260
Joined: 28 Apr 2015, 23:02
Location: Germany

Re: Disable Warnings for currently unset keys

06 Dec 2017, 10:00

Thank you for your thoughtful reply; there's a lot I can learn from it. I hadn't been aware of boundfunc objects; they look indeed like a great way to reduce rote repetition in a case like this. If I understand it correctly, I will still need the individual OriginKey:: entries for each (which are not in your example), but I can then cluster them in front of the calls to f() and g().

It's interesting that you split up the functionality into the up and down events. Does that give you tighter control over the erratic behavior of some keys, which I mentioned at Remapped hotkeys behave strange in other locales, where they keys don't behave as one would expect from the documentation?
A_AhkUser
Posts: 1147
Joined: 06 Mar 2017, 16:18
Location: France
Contact:

Re: Disable Warnings for currently unset keys

07 Dec 2017, 13:42

Micromegas wrote:I will still need the individual OriginKey:: entries for each
I don't understand, you'll always need to specify an origin key to define create a hotkey.
Micromegas wrote:It's interesting that you split up the functionality into the up and down events.
I didn't: as I said I simply quoted the documentation wich states that a script containing a::b actually contains two subroutines for the down and up events, respectively.
Micromegas wrote:Does that give you tighter control over the erratic behavior of some keys, which I mentioned at Remapped hotkeys behave strange in other locales, where they keys don't behave as one would expect from the documentation?
Unfortunatly, I cannot even reproduce this behavior since I cannot switch keyboard locale in my machina... For example, in order to write let's say μΩς ;) I must use a site like Lexilogos...
my scripts
User avatar
Micromegas
Posts: 260
Joined: 28 Apr 2015, 23:02
Location: Germany

Re: Disable Warnings for currently unset keys

07 Dec 2017, 15:14

A_AhkUser wrote:I don't understand, you'll always need to specify an origin key to define create a hotkey.
Don't worry, there's not much to understand. I simply had at first assumed that your code was complete, and only later realized that the :: entries were missing.

Thank you also for your other explanations. I believe we're much more in agreement than you think; it's just that we use some wording differently. The proof, of course, is in the pudding, but that'll have to wait a bit as I'm currently distracted. I just wanted to reply quickly to show you that I appreciate your answer.

Return to “Ask for Help (v1)”

Who is online

Users browsing this forum: todd and 147 guests