In-Browser Edition seems to have NumLock Disabled.

[circe]

When using In-browser, (on Windows) NumLock key does not make RH Keypad numeric for all keys. In particular, the 2,4,6 & 8 keys act as Arrow keys. The same program when compiled for Windows, behaves as expected.
For Example, in program: https://tinyurl.com/Au-Vache
Is this behaviour to be expected, or just my system (W11)?

[Richard Russell]

Is this behaviour to be expected, or just my system (W11)?

It's impossible to say whether it's "just your system" but it doesn't happen here when I run the in-browser version of BBC BASIC for SDL 2.0 in Chrome on a Windows 10 PC. So it's not "everybody's system" at least!

However I know that there can be issues with the NumLock key because SDL seems (on Windows at least) to have no way of reliably determining the 'internal' state of that key. It toggles the state when the key is pressed, but it's possible to get into a situation where SDL thinks NumLock is set but Windows doesn't, or vice versa.

Possibly it depends on what state NumLock is in when BBC BASIC (and hence SDL 2.0) is started, but I've not investigated further. The same thing can happen with the CapsLock key I would expect.

[circe]

Thank you Richard. Trying to understand this I wrote a few lines:
REM!Appname Keytest
PRINT"Press a Key:":REPEAT:x=INKEY(2000):PRINT'"Value="x"-Character="CHR$x;:PRINT:UNTILx=27

This returns Key value and Character when executed, except that when tested as an In-browers app, it sometimes returns two characters. For instance pressing "2" on the numeric keypad returns 138,50. Pressing Main keyboard "2" returns a single 50.
Using the supplied "C:\Program Files (x86)\BBC BASIC for SDL 2.0\examples\general\dlgdemo.bbc" the numberic keypad does not work as expected, so it is not just my program!
Problem occurs on W10 and W11, but keyboard is shared. Could it be a rogue keyboard?

[Richard Russell]

when tested as an In-browers app, it sometimes returns two characters. For instance pressing "2" on the numeric keypad returns 138,50. Pressing Main keyboard "2" returns a single 50.

Yes, my understanding is that this is a direct consequence of SDL2's idea of the state of the NumLock key disagreeing with Windows' (or the browser's) knowledge of the state of the key. When they are 'in step' I believe everything works as it should, but when they are 'out of phase' you get the effect you describe.

You can put this to the test by writing a program which displays (what BBC BASIC believes is) the state of the NumLock key - somewhere I have a program which graphically displays all the various Control, Shift and Lock keys. Then you can try running it on different platforms to see whether you can get it into an 'out of phase' state. I will be interested to learn what you find.

[circe]

On my keyboard at least, there is a Numlock indicator and it gives every appearance of telling the truth. numlock key appears to be totally hardware on this keyboard. Using the one-line-program above, the lumlock key is not seen by INKEY, in either run or in-browser.
As mentioned earlier, using in-browser the "1" key (for instance) returns 141 followed by 49. Using BB4W, the 1 key returns either141 or 49, depending on the state of the Numlock.
The table in the manual under INKEY seems to be in error for Numeric Keypad values for Numlock On and Off.
Interestingly, the numeric keypad "5" returns 53, same as for 5-key on main keypad, and not 124 as per table.

[Richard Russell]

On my keyboard at least, there is a Numlock indicator and it gives every appearance of telling the truth

The NumLock indicator is driven by the OS so should always correspond to the 'truth'. But the NumLock state as seen by SDL is another matter, and it's when that gets out-of-step with the truth that I believe the issue arises.

You can probably work around the problem by ensuring that the NumLock key is always in a specific state when you run your program. This was discussed at length at the relevant SDL forum.

[circe]

The Numlock State can be tested (I have found) by pressing the Numeric 5 Key. If Numlock is Off INKEY gets no response, but if Numlock is on, 53 (Character 5) is returned. 5 is the only Numeric key with no action if Numlock Off.
All other keys return two characters when Numlock is On.

[Richard Russell]

If Numlock is Off INKEY gets no response, but if Numlock is on, 53 (Character 5) is returned. 5 is the only Numeric key with no action if Numlock Off.

It's not clear from that whether you are agreeing with me or disagreeing with me, because you make no reference to SDL's idea of the NumLock state!

But I can confirm, again, that here (using Chrome browser in Windows 10) it works exactly as I described, and therefore it's straightforward to make it work correctly, that is with NumLock off the keypad generates only cursor functions and with NumLock on it generates only digits.

So since it works 'as expected' (albeit not ideally, but that's outside my control) I'm calling this 'completed'.

[circe]

Maybe it is because I am using Firefox as default browser?
Could it be that Chrome is seeing the two characters that are returned, and selecting the character according to its understanding of the Numlock state, whereas Firefox just takes the first character? I wonder...

[Richard Russell]

Maybe it is because I am using Firefox as default browser?

It is not clear to me that it is working any different for you than it is for me, you've not said, so it's premature to suggest that the browser is a factor; personally I think it's unlikely.

If you are convinced that you are experiencing something different from what happens here, please tell me in what way it is different. As I have said, here the behaviour depends on whether SDL's idea of the NumLock state agrees or disagrees with Windows' idea of the NumLock state.

If they agree everything works as you would hope: if NumLock is off pressing a key in the numeric cluster returns a cursor movement code and if NumLock is on the key returns a digit.

If they disagree it works as you have described: if NumLock is off pressing a key in the numeric cluster does nothing but if NumLock is on the key returns two codes.

Since SDL seems to assume that the initial state of the NumLock key is off, that is what you should ensure is the case to keep them in phase.