Sign in to follow this  
Postie

[SlimDX] Keyboard Raw Input - obtaining ASCII values?

Recommended Posts

Postie    1559
I'm working on a game project in SlimDX + DX9 at the moment where I'm using the RawInput API to get keyboard input as this seems to be the "recommended" way.

For most of the functionality I've required up to now this has been sufficient. However, I'm now extending my windowing system to include a textbox control, and I'm having trouble translating the keyboard values coming back from the [font="Courier New"]KeyboardInputEventArgs[/font] into the ASCII characters that I need to put into the Textbox.

The [font="Courier New"]Key[/font] member has no concept of upper and lower case, and I've thought about handling that myself through testing if the shift key is pressed or capslock is on. I got that working, but I've run into an issue with other keys, such as the number keys across the top of the keyboard.

In [font="Courier New"]Key[/font] these are returned as [font="Courier New"]D0[/font] through [font="Courier New"]D9[/font], and its occurred to me that interpreting these values manually for the shift state is going to be a nightmare since keyboard layouts are different depending on the country. A simple example is that shift-3 is a "#" on my keyboard, but in the UK I believe it is a pound symbol.

I've looked into various ways of converting the Key values to ASCII, such as by using unmanaged calls like MapVirtualKey(), but haven't had much success.

The only thing I've had work thus far is adding a KeyPress Event handler to the RenderForm, which returns a [font="Courier New"]KeyChar[/font] value which is exactly what I want, but that approach is going to be very messy as I'll still have to handle other keypresses for extended keys like the cursors or Ctrl-C, Ctrl-V through the RawInput mechanism or the KeyUp/KeyDown events.

I should mention that I've completely rolled my own Windowing/UI system, so there aren't any standard windows controls anywhere to be seen, except the main RenderForm. (I've seen a few suggestions around that make use of the standard controls as part of the solution).

My guess is that the KeyPress event handler is going to be the way to go, but figured I'd throw the question out there and see if the community has any ideas.

Anyone have any insights?

Share this post


Link to post
Share on other sites
fenghus    187
*bump*

I've also searched high and low how to do this but failed. It's apparent that the e.Key value alone isn't enough information to derive the character, so is there a way to query or build a state of the keyboard to send to some conversion utility?

Share this post


Link to post
Share on other sites
Mike.Popoloski    3258
Raw input is, as you may guess, *raw*. This means that if you want the higher level functionality, such as found in standard UI controls, you should make use of that functionality that's already given to you via other Window events. The same is true for mouse input. Many people try using raw input for the mouse, only to realize that when using that data to control a mouse pointer, it doesn't operate as expected, since Win32 does processing to provide advanced pointer ballistics that many people come to expect from a pointer.

Share this post


Link to post
Share on other sites
Flimflam    665
RawInput may be a preferred means of input for something like gameplay, but it's certainly not recommended for UI functionality. As you've seen you have no real access to higher level functions like casing.

You should be reading windows messages for this sort of information. It may seem messy to you but it is proper. Continue subscribing to the form's KeyPress event handler to get the information you seek.

Share this post


Link to post
Share on other sites
Postie    1559
Heh after my post dropped off the first page without a response I figured nobody could be bothered answering so I decided to bite the bullet and just include the Keypress event despite the "messiness". My implementation actually turned out better than I was expecting, so I'm happy with the way it works now.

My [font="Courier New"]WindowManager[/font] class ended up with a [font="Courier New"]ProcessASCIIKeyEvent()[/font] method which is passed a [font="Courier New"]KeyPressEventArgs[/font] directly from the [font="Courier New"]KeyPress[/font] handler. I left the existing [font="Courier New"]ProcessKeyEvent()[/font] method which is passed a [font="Courier New"]KeyboardInputEventArgs[/font] from RawInput to manage the other keys, such as when you hold down a movement key.

I guess I had a misconception about what the best practices were for keyboard input.

I actually noticed the different pointer ballistics when I tried to implement a custom mouse pointer using a Sprite that is positioned based on the mouse position provided by RawInput. If you left the default cursor switched on, the sprite would lag behind it quite a lot, and with the standard cursor switched off the mouse movement felt unnatural. I suddenly realised I'd noted than in the UI for other games I've played where the mouse just doesn't seem right. I abandoned the Sprite idea very quickly, switched to a Custom Hardware Cursor and fixed the problem.

Cheers for the help.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this