Taking input into inputbox with direct input

Started by
11 comments, last by stupid_programmer 16 years, 1 month ago
Hi, Direct Input can be used in games. For example you can move camera with direct input. I write now input box in directx and i heard that you can use direct input for take the input to the inputbox. I rode the direct input tutorials and they doesnt help. I mean: when i push for example key 'k' on my keyboard and then i render it they shows many letters 'k' because of sensivity that direct input have. How must i do: when i push key 'k' they show only one letter 'k' and no many letters 'k'.
Advertisement
First: using DirectInput is no longer recommended. With the speed of today's processors, it is much simpler to use an OnKeyDown() routine or WM_KEYDOWN.

Second: There are DirectInput examples in the SDK. Your best bet is to study how DirectInput is setup.

Third: there are 2 modes for DirectInput - immediate and buffered. Acquiring keyboard data differs between the two modes. Again, I suggest studying the SDK example.

Hope that helps.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

Yes. You could use DirectInput. Equally, you could use BIOS interrupts to manage keyboard input. It's an equally good idea. Faster, but far far more complicated.

You should never be using DirectInput for keyboard or mouse input.

EDIT: Actually, the problem you're having is directly related to using DirectInput. Ditch it and use Window messages or some alternative for your own sanity.
I wouldn't advise using DirectInput for any kind of keyboard input, but for this kind of situation you absolutely don't want DI. For any kind of keyboard input that's used for edit boxes, say for entering a name, you want your game to respond just like a normal Windows Edit control would. This means you want capslock and shift to work, you want they key to auto-repeat if it's held down, and you want to allow for alternate keyboard arrangements and different language configurations. None of those things are supported in DirectInput, but they are if you simply process WM_CHAR messages.
I always used DirectInput or GetAysncKeyState so I didn't have to wait a second for they key to start repeating if the user kept pushing it.
Quote:Original post by stupid_programmer
I always used DirectInput or GetAysncKeyState so I didn't have to wait a second for they key to start repeating if the user kept pushing it.
If you've received a WM_KEYDOWN message and no WM_KEYUP message, then the key is pressed. There's no need to use DirectInput.

EDIT: Actually, all you're doing is warping Window messages to do what you want them to do. There's no difference between trying to get key repeat from a method that doesn't provide it, and trying to remove key repeat from a method that provides it.

Actually, the above method can have some problems if the user alt+tabs with the key held (Since you won't get the key up message). But if you get a WM_ACTIVATE message saying your window has just become focused, you should probably clear your held keys anyway.
Quote:Original post by kacperz1
So it must be like this?
		case WM_CHAR:		{			switch(wParam)			{				default:					std::cout << wParam;					break;			}		}		break;


But the wParam contains not the name of the character but him number. what must i do?
wParam is the character code. If you want to print it out, you'll need to cast it to a character, like so:
std::cout << (char)wParam;
Original post by kacperz1
I dont want to handle the messages into the messages procedure but in my function.


But that's exactly what the message procedure is for. If you want to handle the specific WM_CHAR message somewhere else, then have your window procedure forward the message to whatever function you want to handle it.

Quote:Original post by MJP
But that's exactly what the message procedure is for. If you want to handle the specific WM_CHAR message somewhere else, then have your window procedure forward the message to whatever function you want to handle it.


This is why I always used DirectInput. I use states and a game manager class to control the game so I would have to forward the data from WM_CHAR a few times to get it to where the game is actually checking input.

Quote:Original post by stupid_programmer
Quote:Original post by MJP
But that's exactly what the message procedure is for. If you want to handle the specific WM_CHAR message somewhere else, then have your window procedure forward the message to whatever function you want to handle it.


This is why I always used DirectInput. I use states and a game manager class to control the game so I would have to forward the data from WM_CHAR a few times to get it to where the game is actually checking input.
Then you're missing out on all the things that Windows provides, like key repeat. It's not such a big deal if you just need to know if a key is up or down, but it is if you're doing any sort of text input, you want to support any language other than English, or you want to support lower / upper case and shifted characters.

Just because DirectInput seems easier to do here, doesn't mean it's a good idea. Hell, you can write to specific memory addresses to call BIOS interrupts or similar, and that's easier - but it's really not a good idea.

This topic is closed to new replies.

Advertisement