Sign in to follow this  

KEYUP + Shift key

This topic is 4106 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

Im having trouble determining when a key is let up. [edit - correction] I used WM_CHAR to check for the input, but I'm not sure what command to check that takes the shift/capslock keys into consideration with KEYUP. The following method worked for letters, but other spots on the ascii chart do not use the same positioning so I am a little confused of how to offset the value.
char c = (char)wparam;
if((c >= 65) && (c <= 90))
	pInput->SetKeyUp(c + 32);

pInput->SetKeyUp(c);



[Edited by - JeremyCAFE on September 17, 2006 11:39:37 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by JeremyCAFE
Im having trouble determining when a key is let up. I used WM_CHAR to check for the input, but I'm not sure what command to check that takes the shift/capslock keys into consideration.

The following method worked for letters, but other spots on the ascii chart do not use the same positioning so I am a little confused of how to offset the value.

*** Source Snippet Removed ***


WM_CHAR automatically takes the shift key and caps-lock into consideration.

Share this post


Link to post
Share on other sites
I am using WM_CHAR to check for a key press, but I need to determine when the key us unpressed. I was just hoping there was a way to do it without having to check the character and then translate.

I can turn a letter off no matter what. My problem is the rest of the ascii chart.

edit: Sorry, I realized my initial post was misleading as to what I was asking.

Share this post


Link to post
Share on other sites
Would using WM_KEYDOWN instead of WM_CHAR make things easier? WM_KEYDOWN corresponds more closely to WM_KEYUP than WM_CHAR does.

Think about it this way: You can't have a lowercase 'c' and a capital 'C' pressed at the same time, nor a capital 'A' and a lowercase 'z'.

Share this post


Link to post
Share on other sites
Let me better explain my issue.

I have my buffer of input that stores if a key has been pressed. When WM_CHAR tells me a key is pressed, it flag the character in the buffer as down.

My problem is, when I get WM_KEYUP it is only returning one version of the key. Say if 1 was pressed and let go. If KEYUP tells me ! has been released, I need to manually check which key is pressed and hardcode the partner key to turn off also.

Share this post


Link to post
Share on other sites
I'm not the best programmer in the world, but couldn't you just...

case WM_KEYDOWN:
{
bool IsShift = false;
if(GetAsyncKeyState(VK_SHIFT)) IsShift = true;
switch(LOWORD(wParam))
{
case VK_LEFT: //Left arrow key
//Move cursor back along buffer
break;
case VK_RIGHT: //Right arrow key
//Move cursor forward along char buffer
break;
case 0x43: //Or whatever is 'A' charactor...
if(IsShift)
{
//Add 'A' (capilized) to buffer
}
else
{
//Add 'a' (lowercase) to buffer
}
break;
case VK_ESCAPE:
//Exit app
break;
}
}



Pardon my ignorance, if this is not what you're looking for.

Share this post


Link to post
Share on other sites
Why does your input state need to know whether a capitalized key is down? What if you pressed shift, pressed 'c', released shift, and keep holding 'c' down? Is capital C down or up? Is lowercase c down or up? They are the same physical key!

Your 'buffer' that you mention is not a sequential buffer, but a state table, correct?

Use WM_KEYDOWN since it will not care whether shift or caps is down.

Share this post


Link to post
Share on other sites
There are three main ways of dealing with WM_KEYDOWN, WM_KEYUP, and WM_CHAR.

1: WM_CHAR is supposed to be used in situations where you need human-readability taking keyboard layout and language settings into account. In a game development scenario, WM_CHAR should only be used for command prompts and chat dialogs. In these cases, shift state matters only when a key is pressed, and is automatically factored into WM_CHAR for programmer ease. There is no need to deal with key-ups.

2: WM_KEYDOWN and WM_KEYUP can be used when you need to know when multiple keys are being held at the same time (such as walking forward and turning/strafing at the same time). You don't care about shift+key combos because shift is simply treated as just another physical key.

3: WM_KEYDOWN and WM_KEYUP can be used to record the exact sequence of keys pressed and released and incorporate delays, which allows a macro utility to play the same sequence back exactly. Shift keys are also treated as yet-another-key.


#2 sounds like what you're trying to do, but you mention 'buffer', which implies a stored sequence, which is #3.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
my use of terms is probably rather off. I am still an early student so please forgive me :)

The reason I need to know the difference is because this is for chat input.

I was trying to mock the way every text editor works with holding a key down. I noticed it pauses for a second, and then continues to spam. To do this I set a flag that the key was down and when it was pressed. I only spam the key when it has been down for longer than .5 seconds. I am 100% sure this is a poor way of doing it. I just couldn't think of any other way.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
I was trying to mock the way every text editor works with holding a key down. I noticed it pauses for a second, and then continues to spam. To do this I set a flag that the key was down and when it was pressed. I only spam the key when it has been down for longer than .5 seconds. I am 100% sure this is a poor way of doing it. I just couldn't think of any other way.

Can't you request the OS to send you repeat keydown events? This is how it is done on a Mac, and it gives you the users keyboard repeat rate settings too (sorry, not familiar with the Windows API).

Share this post


Link to post
Share on other sites

This topic is 4106 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.

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