Page 1 of 1

Remapping keyboard and noticed a strange backspace glitch

Posted: 14 Feb 2018, 01:18
by player2N64
Hello, sorry if this is a poor post I am new to the forum and just had a quick concern. I am using AutoHotkey to remap my keyboard entirely to learn a better typing method. I first encountered a problem when trying to set the # key on my keyboard (shift + 3) to a square bracket ( [ ). My keyboard would always produce curly brackets ( { ) instead of square brackets when I used code like this:

Code: Select all

 #::[
It started to work when I changed to the following:

Code: Select all

 #::send, [
This is an aside, but I'm confused why the original method only let me type curly brackets... If anyone knows, thanks in advance for explaining.

Anyways, when I finally got it working, I wanted to test it by just typing the square bracket a bunch, and I would type it and backspace repeatedly, very quickly. I then noticed that the curly bracket would be typed again instead of the square bracket sometimes! I thought it was a problem exclusive to these brackets but I started trying the same typing and deleting with other shift+number remaps and a similar phenomenon occurred. I will just post my current progress here if someone wanted to test what I meant...

Also, just before posting this I noticed that this issue only occurs when my enter key is a hotkey for backspace. The regular backspace does not ever produce the same issue. Furthermore, I tried adding the wildcard on the hotkey and it made it so that instead of a curly bracket accidentally being posted an @ sign was posted instead. With the wildcard applied the key that shows up unintentionally is the key that used to exist there originally (i.e. since I press shift + 2 to get a square bracket, the @ sign sometimes shows up instead since that is typically what is produced on a QWERTY keyboard layout).

I also tried looking that the KeyHistory... but I couldn't figure out why the problem would be occurring (I understood what it was showing me, just not what to make of it since I didn't see a pattern in successful [ prints vs. @ prints).

Code: Select all

#ifwinactive


;     ~ ROW

`::\
~::^
!::~
@::send, [
#::+sc01A
$::<
%::|
^::sc006
&::>
*::+sc01B
(:: send, ]
)::#
_::Q
+::Z
6::0
7::6
8::7
9::8
0::9
-::q
=::z
backspace::capslock

;    TAB ROW

q::y

;    CAPS LOCK ROW

enter::backspace
capslock::enter
I am new to AutoHotkey and scripting and programming in general, sorry. Thanks for listening.

Re: Remapping keyboard and noticed a strange backspace glitch

Posted: 14 Feb 2018, 06:26
by Ravenlord
It's because You are replacing(remapping) # with [
After pressing Shift + # (which is now [ ), it gives as result { because it's effect of pressing shift+[
# pressed without shift should work as intended (You can test it with any letter or sign which don't require additional key to activate for example number 3)

Re: Remapping keyboard and noticed a strange backspace glitch

Posted: 14 Feb 2018, 15:35
by player2N64
Hello thanks for the reply. Yeah, I figured that that was the problem so I changed it to *@ . It doesn't make sense to me because I don't know how AutoHotkey interprets key presses since I figured "@' was only viable in the standard keyboard provided that you are holding shift, so it didn't make sense to me that it would then apply shift to the result since the result should be different from the input. That's just my opinion on the matter but like I said I don't know how it actually works.

Re: Remapping keyboard and noticed a strange backspace glitch

Posted: 17 Feb 2018, 00:05
by lexikos
the # key on my keyboard (shift + 3)
This is not a key. It is two keys; a key combination.

See remapping.
When a script is launched, each remapping is translated into a pair of hotkeys. For example, a script containing a::b actually contains the following two hotkeys instead:

Code: Select all

*a::
SetKeyDelay -1   ; If the destination key is a mouse button, SetMouseDelay is used instead.
Send {Blind}{b DownR}  ; DownR is like Down except that other Send commands in the script won't assume "b" should stay down during their Send.
return

*a up::
SetKeyDelay -1  ; See note below for why press-duration is not specified with either of these SetKeyDelays.
Send {Blind}{b up}
return
See also {Blind}.
Furthermore, I tried adding the wildcard on the hotkey [...] With the wildcard applied the key that shows up unintentionally is the key that used to exist there originally
#::[ uses a wildcard implicitly, as noted above, and adding another wildcard would not have any effect. #::Send [ does not include a wildcard, so cannot be triggered if surplus modifiers are down (such as Ctrl/Alt/Win). Adding the wildcard would also require the keyboard hook to be used, whereas normally the "reg" method could be used. You can check this by using ListHotkeys.