Jump to content

  • Log In with Google      Sign In   
  • Create Account


RawInput, ascii and deadkey characters


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Syranide   Members   -  Reputation: 375

Like
0Likes
Like

Posted 30 January 2012 - 05:43 AM

RawInput seems to be what everyone suggests doing nowadays, got it up and running quite easily. Found some useful information to fix some of it issues and it's working really well for virtual keys now. The documentation was lacking and incorrect in some aspects it seems.

However, translating that into printable ascii characters turned out to be harder than I thought, and I still haven't found any implementation that actually works properly with deadkey characters, combining ` and u into ù if typed in that order. I have seemingly tried all combinations of ToAscii and GetKeyboardState, and everything in-between but can't find a solution that work 100%, and produces the correct results like WM_CHAR does.

WM_CHAR works for me, but it would be nice to only use RawInput for the input. Does anyone have an idea how to properly do this, or know of any existing project with source code that does this?



Sponsor:

#2 turch   Members   -  Reputation: 590

Like
1Likes
Like

Posted 30 January 2012 - 08:16 AM

RawInput only tells you what keys are down, there is absolutely no processing done on them. Character combinations are all handled by a higher level. If you want that functionality, you will have to write it yourself.

#3 Krohm   Crossbones+   -  Reputation: 2961

Like
0Likes
Like

Posted 30 January 2012 - 09:03 AM

WM_CHAR works for me, but it would be nice to only use RawInput for the input. Does anyone have an idea how to properly do this, or know of any existing project with source code that does this?

No, it wouldn't. What's the deal with raw input? Low level state. Personally I use it for mouse movements only.
WM_CHAR does exactly what you need: mangle the low-level information to a character allowing for input editors. Using both is possible and in my opinion, very advisable.
How much to implement WM_CHAR mangling? For me, it's about 6 LOC. I think it's not enough to call for "replication".
BTW, have you tried using non-qwerty layouts? That's not a problem with WM_CHAR.

The two APIs do different things and they do at very little cost. In my opinion, trying to work around the limitations of one to obtain the other is just wasted effort. What's the problem in using both?

#4 Syranide   Members   -  Reputation: 375

Like
0Likes
Like

Posted 30 January 2012 - 09:45 AM

Thanks for the replies, I should've perhaps stressed that point more, but this is not an issue in any way, but it would be interesting to solve.

From what I've read and understand it's completely possible and even referred to in the documentation I believe, that one can simply use ToAscii or ToUnicode and you get the same functionality as WM_CHAR, but with the benefit of being able to enable NOLEGACY and do away redundant processing... again, not an issue, in any way... but it's meant to be possible and I'm unable to get it to fully work myself, and can't find anyone else who have done it properly and presented code.

So I'm curious if anyone has actually been able to get it to work.
If not, then WM_CHAR works just as well and I'm not really bothered, but it would still be nice.



#5 turch   Members   -  Reputation: 590

Like
1Likes
Like

Posted 30 January 2012 - 10:13 AM

I've emulated input processing using raw input before when I couldn't use WM_CHAR for various reasons. I had a structure that kept track of which keys were pressed and released, and #defined a character code for each character. Each code was stored in 16 bits, with the low 8 used for the "base" key, and the high 8 used for various modifiers (alt, shift, caps lock).

There was a look up table with each key, and when any other part of the program was sent input, it used the table to convert the key code into something specific.

Holding down shift + a, for example, sent the following binary info
00000001 00010100

If the input receiver wanted an actual character they would look up the entire number in the array and get back A. This happened when the user was typing into a console.
If they only cared about the key that was pressed, they masked off the high 8 bits and looked up the low 8 bits, getting back a. This happened when the user was running forward with a and pressing shift to sprint (the shift was also sent as a separate input event).

It has some inefficiencies, but when you consider the frequency of input events (maybe 2 / sec = 1 / 30 frames) you can do pretty much anything and it won't really matter.

#6 Syranide   Members   -  Reputation: 375

Like
0Likes
Like

Posted 30 January 2012 - 10:22 AM

I've emulated input processing using raw input before when I couldn't use WM_CHAR for various reasons. I had a structure that kept track of which keys were pressed and released, and #defined a character code for each character. Each code was stored in 16 bits, with the low 8 used for the "base" key, and the high 8 used for various modifiers (alt, shift, caps lock).

There was a look up table with each key, and when any other part of the program was sent input, it used the table to convert the key code into something specific.

Holding down shift + 1, for example, sent the following binary info

00000001 00010100

If the input receiver wanted an actual character, they would look up the entire number in the array and get back !
If they only cared about the key that was pressed, they masked off the high 8 bits and looked up the low 8 bits, getting back 1


True, but getting the printable character is not really an issue with RawInput using ToAscii, however, if you want dead keys to work properly, and a few other minor issues it seems, then you need to feed ToAscii the keyboard state, as is done with GetKeyboardState, however, doing that I've never really been able to get it to work. If I enable NOLEGACY then I even only get lower case chars, which makes me curious if NOLEGACY also prevents GetKeyboardState from doing it's job, so then I would have to implement that myself, no problem, but how would one know which keys are toggleable, or when to "untoggle" them, i.e the dead keys, which would be required to properly the dead key with whatever is pressed aftwards. Note, ToAscii and ToUnicode specifically has this functionality.

And I tried to emulate it using WM_KEYDOWN and using ToAscii, I indeed got it to work, but not 100%. The order in which you released the keys incorrectly affected the output and there were a bunch of other issues too.

It seems like there should be an easy way to do this as it's the reason why ToAscii and ToUnicode exists it seems, however I have yet to see any source code that uses them to achieve the proper result and I'm unable to myself.



#7 turch   Members   -  Reputation: 590

Like
0Likes
Like

Posted 30 January 2012 - 10:39 AM

but how would one know which keys are toggleable, or when to "untoggle" them


That was the responsibility of the input class (the level between the raw input and everything else, which also holds everything else I mentioned). What I made was only for U.S. keyboards, which have no dead keys but use alt + keypad to emulate them. So when alt was held down, in addition to tracking regular input, it would track what numpad keys were pressed, and when alt was released, converted the strokes into the appropriate character. This character was sent as part of the alt release message, so again if the receiver was interested in the character, they convert the whole thing into say é. If the receiver was only interested in the actual keys pressed, they used the bit mask, which turned it into a simple alt release.

I'd imagine it would be similar with actual dead keys. When a dead key is pressed, send a regular key press message (when cast to a character, casts to NULL), and keep track that a dead key is pressed. When the next key is pressed, create the appropriate code that, when cast to a character will return ù or whatever, but when cast to a key will return just u.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS