INKEY

[Local Body]

Maybe I missed something, but using INKEY Alt-1, Alt-0, etc., do not return a code, for example, @ 226
Inkey /k"[Alt-1][Alt-0]" /x %%ch

 

[Local Body]

combinations are not processed - Alt-0 Alt-1 Alt-2 Alt-3 Alt-4 Alt-5 Alt-6 Alt-7 Alt-8 Alt-9

 

[vefatica]

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

do forever
    inkey /x /p /c %%foo
    echo %@ascii[%foo]
    delay 1
enddo

and pressing Alt-1 through Alt-9, I get

v:\> inkeytest.btm
1
2
3
4
5
6
7
8
9

I get no output from Alt-0 (but then, ASCII character 0 is a NUL character).

 

[Local Body]

I need such a line here and it does NOT work. Until about version 24, there were no problems. Pressing Alt-1 returned the code @ 226, Alt-0 returned the code @ 235. Thank you, I will change these keyboard shortcuts to others.

 

[vefatica]

I need such a line here and it does NOT work. Until about version 24, there were no problems. Pressing Alt-1 returned the code @ 226, Alt-0 returned the code @ 235. Thank you, I will change these keyboard shortcuts to others.

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.

 

[rconn]

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.

 

[vefatica]

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.

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.

 

[rconn]

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.

 

[vefatica]

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,

do forever
    inkey /x /p /c %%foo
    echo %@ascii[%foo]
    delay 1
enddo

here's Alt-(KP)1 followed by Alt-1.

v:\> inkeytest.btm
64 55 57
1

In addition, Alt-(KP)1 and Ctrl-(KP)1 produce the same output (64 55 57) ... WAD?

 

[rconn]

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.

 

[vefatica]

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.

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.