To save others some time: When
numlock is
ON, and numpad inputs numbers, holding
shift changes its state back to normal (
numlock off), except it then treats the keystrokes as if
shift wasn’t pressed, meaning that this
shift doesn’t hold the text anchor and so moving the cursor using
shift +
numpad when
numlock is
ON will not select the text as it is the case when moving the cursor by using
shift +
numpad when
numlock is
off.
Moreover, if you hold both
Shifts when
numlock is
ON, you will select the text, because one
shift will invert the
numlock state and another will act normally.
Tested on W10.
It’s hard to say if it’s a bug, but I think it’s inconsistent with how AHK does the job for you when you remap a small letter and it automatically remaps a capital letter:
Code: Select all
a::LShift ; works, because A is remapped too, so once shift converts a UP to A UP, it still gets remapped to LShift UP
It also automatically remaps special characters together with digits below them, automatically remaps the question mark with the slash etc. It will even make this work:
Even though once you push
Pause down, you send
LCtrl down, and therefore when you release
Pause it actually should be
Break Up?
Edit: however, here’s an example that proves consistency in this unexpected behavior:
Code: Select all
While ( 1 ) {
sleep 100
ToolTip % GetKeyState( "Numlock" )
}
Numpad7::NumLock