Archived

This topic is now archived and is closed to further replies.

I need help with DIK...

This topic is 5143 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Let''s say that I want to make a text box in my game (just for an example), so I need to check with DI all the keys, and check if some key is pressed... but as I saw in the SDK, those keys are not an ASCII value, so how I can tell which char was pressed with the value that I got? if something is not understood so tell me...

Share this post


Link to post
Share on other sites
I guess the LONG way..
if (value == DIK_0) string[placeholder] = ''0'';
...
...
...
Till you check all the keys you want (say A-Z, 0-9, shift, enter). If theres an easier way????? I dunno.

Share this post


Link to post
Share on other sites
Try taking your input from somewhere else (like windows) for that part of your code instead of DirectInput.

Also make a search this topic has been discused many times

Share this post


Link to post
Share on other sites
quote:
Original post by ElectronicSandClock
That''s what I wanted to avoid...

thanks anyway.



I know it''s not what you want to hear, but...:

Having been in the position you''re in a few times over the years and having tried both ways, I''d strongly advise you reconsider avoiding WM_CHAR.


By avoiding WM_CHAR, you also "avoid" lots of useful things Windows does for you with that message such as:
- automatic translation to ASCII/UNICODE,
- handling of the Shift and other keys (Alt-Gr etc),
- obeying your users keyboard configuration settings (keyboard repeat, delays etc),
- non-USA keyboard mappings,
- "dead-keys" for accented characters on continental European keyboards (where you press one key, release it and then press another to get an accented character),
- IME for non-Western languages (Japanese etc),
- accessibility tools (sticky keys, speech to text etc)
- ...

You''ll notice a lot of things there which make your application a lot more usable for your users/customers.


The names of the DIK_ codes are only valid for US keyboards - some characters will be different on UK keyboards for example, even more different on German keyboards, more different still on French keyboards and totally wrong for Dvorak keyboards.

Furthermore you don''t get very basic things such as keyboard repeat settings, local keymap translation, and dead keys (essential for supporting the European market when people commonly want to enter characters such as ë, æ and
ø a lot).
To support even those very basic features properly would require a look-up table to translate from DIK_ codes to ASCII codes - this table would need to be different for every keyboard language in use. Things such as key repeat, handling uppercase versus lower case etc would need extra logic in your code. This takes MUCH more code than using WM_CHAR for the text input.


It''s actually very simple to support WM_CHAR for your text input and DirectInput for your gameplay input:

1) Set up your DirectInput keyboard device as usual

2) In the WndProc for your focus window, handle WM_CHAR and forward the ASCII/UNICODE result you get back to whatever does your text box input.

3) Handle lost input devices properly - you''d need to do that to cope with things such as the keyboard being unplugged anyway. It isn''t difficult - just check function return codes and handle accordingly.

4) When you are in gameplay mode, Acquire() the keyboard as usual.

5) When you need the player/user to input some text, simply Unacquire() the keyboard device and you''ll start getting WM_CHAR messages.

6) Finally to go back to gameplay mode, Acquire() again.

--
Simon O''Connor
3D Game Programmer &
Microsoft DirectX MVP

Share this post


Link to post
Share on other sites
quote:
Original post by S1CA
quote:
Original post by ElectronicSandClock
That''s what I wanted to avoid...

thanks anyway.



I know it''s not what you want to hear, but...:

Having been in the position you''re in a few times over the years and having tried both ways, I''d strongly advise you reconsider avoiding WM_CHAR.


By avoiding WM_CHAR, you also "avoid" lots of useful things Windows does for you with that message such as:
- automatic translation to ASCII/UNICODE,
- handling of the Shift and other keys (Alt-Gr etc),
- obeying your users keyboard configuration settings (keyboard repeat, delays etc),
- non-USA keyboard mappings,
- "dead-keys" for accented characters on continental European keyboards (where you press one key, release it and then press another to get an accented character),
- IME for non-Western languages (Japanese etc),
- accessibility tools (sticky keys, speech to text etc)
- ...

You''ll notice a lot of things there which make your application a lot more usable for your users/customers.


The names of the DIK_ codes are only valid for US keyboards - some characters will be different on UK keyboards for example, even more different on German keyboards, more different still on French keyboards and totally wrong for Dvorak keyboards.

Furthermore you don''t get very basic things such as keyboard repeat settings, local keymap translation, and dead keys (essential for supporting the European market when people commonly want to enter characters such as ë, æ and
ø a lot).
To support even those very basic features properly would require a look-up table to translate from DIK_ codes to ASCII codes - this table would need to be different for every keyboard language in use. Things such as key repeat, handling uppercase versus lower case etc would need extra logic in your code. This takes MUCH more code than using WM_CHAR for the text input.


It''s actually very simple to support WM_CHAR for your text input and DirectInput for your gameplay input:

1) Set up your DirectInput keyboard device as usual

2) In the WndProc for your focus window, handle WM_CHAR and forward the ASCII/UNICODE result you get back to whatever does your text box input.

3) Handle lost input devices properly - you''d need to do that to cope with things such as the keyboard being unplugged anyway. It isn''t difficult - just check function return codes and handle accordingly.

4) When you are in gameplay mode, Acquire() the keyboard as usual.

5) When you need the player/user to input some text, simply Unacquire() the keyboard device and you''ll start getting WM_CHAR messages.

6) Finally to go back to gameplay mode, Acquire() again.

--
Simon O''Connor
3D Game Programmer &
Microsoft DirectX MVP


A BIG THANK YOU!!!

Share this post


Link to post
Share on other sites