PB's keyboard library and "problematic" keys

[luis]

storing scan codes make no sense as someone with two keyboards that hit the same key may generate different scancodes

Yes, but I was believing at least scancodes were unique for each key on a specific keyboard.

I discovered it's not so. For example on some keyboards the digits on the keypad have the same scancodes as the first row of digits from left to right. On others, like mine, the scancodes of the keypad's home, end, pgup, pgdn are the same as in the brown group just left of the keypad and so on.

I though scancode could have been useful in some cases, for example because they remain constant for the keypad independently from the num/lock status, while the virtual codes generated are depending from it.

But even if used in mapping mode (the user press the key it want to be associated to a function) the fact they are not guaranteed to be unique inside a single keyboard limit they usefulness.

What once was a standard (the XT keyboard from DOS times) it's not so standard anymore and scancode assignments have taken a wild turn.

Maybe I'll support them anyway, since it's not a burden, and in the worst scenario the user can simply not use them.

[Rescator]

*nods*

For example my mouse is a A4 Tech X7 XL-750BH.
It lets you change the scancodes of it's buttons (aka remapping) and even have 64KB memory for scripts (yeah actual scripts).

For some reason the forward/backwards buttons was sapped by default, changing the scancodes made it behave like expected. (for me at least the front should be forward and rear thumb should be back).
It's also got this odd tripple leftclick/fire button, for fun I changed it to just act as the "i" key.

The cool thing is I can drag this mouse to any computer and it'll still work as I programmed it.

I could also script that button to act as if I wrote "PureBasic" in a certain tempo, even with pauses etc.

So I guess one can only rely on virtual keys.
Care should be taken if relying on scancodes or oem codes.

Obviously with scancodes you can identify each physical button, but in general what most users want is the virtual key mapping (especially if they have programmable mice or keyboards or script/macro support on them etc.)
It's also getting more common with alternate devices that either extend r duplicate features of mice.
Touch displays as well may generate virtual key codes, and these may not even generate the expected scancodes.

The only bad thing is that virtual keys are limited to 255 it seems, a lot of them are duplicate or repeats as well (if you look at the list), oh well...
At least with virtual codes you do not have to keep track of the device name etc, unlike with soundcard inputs/outputs *ugh*.

[eriansa]

Question about scancodes :

Has an "A" on an azerty keyboard the same scancode as a "Q" on a qwerty?

[luis]

From what I understood, you can't know. Depends on the keyboard maker.
If the two keyboards are made by the same maker, with a very high degree of probability the answer is yes.
But different hardware (keyboards) can return different scancodes for keys in the same physical position.

PS: when talking about scancodes, in this thread I always refer to the code returned by the WM_KEY*.* messages.

PS2: if you use the same hardware and simply change the layout using the OS control panel, the answer should be always yes, again from what I have understood.

[Rescator]

In general "most" keyboards have the common keys using the same scancodes, so the likelihood of keyboards having the same scancode for "A" is high, but not guaranteed.
I believe it is possible for a single keyboard to have the same scancode for say A and Q, but in that case the keyboard driver will react to a modifier code sent along to help distinguish between the two.

We already know some of the issue with scancodes or what not when it comes to the Left Shift and Right Shift and Left Control and Right control.
It's entirely possible for a keyboard to report just Shift (Left Shift) for both shift keys, thus never sending a different scancode for the right shift.

It's kinda like the phone number prefix, you can call a number in your area with a prefix, but go to another state and you have no idea who you'll be calling. (here in Norway the prefix got dropped nationwide a long time ago so we don't have that issue any more)

I'm sure there are some really nice info tucked away at MSDN, usually it tends to be an obscure link down a page somewhere with more details on how certain things like this works.
Who knows, half the stuff I said could even be wrong...
Most likely the hard facts on all this can be found in the driver SDK in particular the HID stuff.

[Rescator]

Ah, found this: http://en.wikipedia.org/wiki/Scancode

That shows the issue (with PS2 keyboards).
I guess now I'll have to dig up the USB specs on keyboards and mice and see what those say...

[Rescator]

Ok found some info: http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html
Look way down for the USB info By the looks of it that is the "standard", but what happens when the modifier keys are involved I've no idea.

Also please bare in mind systems with mixed hardware.
It "is" entirely possible for one keyboard (USB for example) and another (PS/2 for example or some other odd device) to report a different scancode for "A".
I believe the scancode you get from the system is the raw one, but the drivers (or OS) will translate this to CHAR or VK codes for you. (check MSDN to confirm this).

[Rescator]

*scratches head*
Ok, I've got no clue here. As per the lParam is seems that the scancode is 1 for my Esc key. But per that USB chart it should be 41, so obviously there must be some translation going on. (I assume the OS notices which family the keyboard belongs to and then translates for the CHAR and VK messages. also note that I have a Norwegian keyboard and a Norwegian layout selected, for all I know the scancode for Esc = 1 on those *shrug*.


My suggestion is to store a user profile using VK or CHAR or similar.
Then when they start the game/program map those to the current scancodes.

That way a change in keyboard, or change in layout, or copying their profile to another computer (or even online profile) wont' force the user to remap their keys every single time.
There is still the issue of a keyboard or device lacking certain keys, in which case that "key" in the profile will just have to be ignored. (but allow the user to change it obviously).