INKEY
- Thread starter WinLanEm
- Start date
If you look at the ASCII value of what's returned, you'll see that they're processed but not in the way you might expect. With this code
and pressing Alt-1 through Alt-9, I get
I get no output from Alt-0 (but then, ASCII character 0 is a NUL character).
Code:
do forever
inkey /x /p /c %%foo
echo %@ascii[%foo]
delay 1
enddo
Code:
v:\> inkeytest.btm
1
2
3
4
5
6
7
8
9I get no output from Alt-0 (but then, ASCII character 0 is a NUL character).
You are quite right. I tried with v16 and v20 and got @226 ~ @235 as you said. I guess we'll have to wait for Rex to chime in.
I also noticed that, in v25, Alt-1 ~ Alt-0 work as expected when assigned to actions in the Option\Keyboard dialog.
This was a deliberate change in v24.
In v23, if you wanted to enter an alt-keypad combination (i.e., holding down the alt key and pressing 0-9 one or more times in order to insert a specific key) it had to be done on the keypad, not using the 1 - 0 keys on the top row of the keyboard. This caused a lot of grumbling from users who either didn't have a numeric keypad (small laptops or mini keyboards), or who didn't want to switch their keypad in & out of numeric mode (with the Num Lock key).
In v24, you can enter alt-keypad combinations either with the keypad or by using the numeric keys on the top of the keyboard. This means that there's no special keys "Alt-0" through "Alt-9" anymore; they're interpreted as requests for the ASCII values 0 - 9.
In v23, if you wanted to enter an alt-keypad combination (i.e., holding down the alt key and pressing 0-9 one or more times in order to insert a specific key) it had to be done on the keypad, not using the 1 - 0 keys on the top row of the keyboard. This caused a lot of grumbling from users who either didn't have a numeric keypad (small laptops or mini keyboards), or who didn't want to switch their keypad in & out of numeric mode (with the Num Lock key).
In v24, you can enter alt-keypad combinations either with the keypad or by using the numeric keys on the top of the keyboard. This means that there's no special keys "Alt-0" through "Alt-9" anymore; they're interpreted as requests for the ASCII values 0 - 9.
How does that help anyone? I don't see an advantage, keypad or no keypad. If you don't have a keypad (or don't want to switch its mode), how do get the old behavior? And if you do have a keypad, why are Alt-N and Alt-(KP)N different.
You cannot get the old behavior.
If you do have a keypad,, the keys are *not* different. An Alt-1 on the keypad is the same as an Alt-1 on the keyboard.
It doesn't seem so. Using this BTM,
Code:
do forever
inkey /x /p /c %%foo
echo %@ascii[%foo]
delay 1
enddohere's Alt-(KP)1 followed by Alt-1.
Code:
v:\> inkeytest.btm
64 55 57
1In addition, Alt-(KP)1 and Ctrl-(KP)1 produce the same output (64 55 57) ... WAD?
I've made a change for build 15 that tries to interpret what the user really wants - if it's an Alt-number on the keypad, it always returns the character matching that numeric value. If it's a single Alt-0 - Alt9 on the numeric row, it returns the extended key value. If it's an Alt + multiple numeric keys on the numeric row, it returns the character matching the numeric value.
This should work in all cases except when the user wants to enter a ASCII 0 - 9 control character; but in that case they could just use Ctrl-A - Ctrl-I.
This should work in all cases except when the user wants to enter a ASCII 0 - 9 control character; but in that case they could just use Ctrl-A - Ctrl-I.
Waiting for Alt to be released is a small annoyance. But I suppose it must be that way to accommodate users without a numeric keypad.
