How to respond VK_LEFT and VK_DOWN at the same time?
-
I want to respond the message VK_LEFT and VK_DOWN at the same time so I can move a object to the buttom-left coner, and I don't want to use DirectInput, is there some way to make that, please? 劍客 賈島 十年磨一劍, 霜刃未曾試。 今日把示君, 誰有不平事?
try
GetAsyncKeyState()
My articles www.stillwaterexpress.com BlackDice -
I want to respond the message VK_LEFT and VK_DOWN at the same time so I can move a object to the buttom-left coner, and I don't want to use DirectInput, is there some way to make that, please? 劍客 賈島 十年磨一劍, 霜刃未曾試。 今日把示君, 誰有不平事?
On a uniprocessor machine, you won't be able to do this as messages are handled one at a time.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
-
I want to respond the message VK_LEFT and VK_DOWN at the same time so I can move a object to the buttom-left coner, and I don't want to use DirectInput, is there some way to make that, please? 劍客 賈島 十年磨一劍, 霜刃未曾試。 今日把示君, 誰有不平事?
You cannot process those messages at the same time. You can however, simulate the behaviour by using some boolean states of which key is down and which key is up:
// In your class that processes the messages:
bool m_bIsVKLeftDown, m_bIsVKRightDown;Second, you need to process the WM_KEYDOWN[^] and WM_KEYUP[^] messages:
// I assume that you are using MFC
// in you class
afx_msg void OnKeyDown(UINT nChar, UINT nRepCount, UINT nFlags)
{
switch( nChar )
{
case VK_LEFT: m_bIsVKLeftDown = true; break;
case VK_RIGHT: m_bIsVKRightDown = true; break;
}CYourDerivedClass::OnKeyDown(nChar, nRepCount, nFlags);
}
afx_msg void OnKeyUp(UINT nChar, UINT nRepCount, UINT nFlags)
{
switch( nChar )
{
case VK_LEFT: m_bIsVKLeftDown = false; break;
case VK_RIGHT: m_bIsVKRightDown = false; break;
}CYourDerivedClass::OnKeyUp(nChar, nRepCount, nFlags);
}
After that, you can move your window how you want depending on the different states. Hope this helps :-D Behind every great black man... ... is the police. - Conspiracy brother Blog[^]
-
On a uniprocessor machine, you won't be able to do this as messages are handled one at a time.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
since they are handled one at a time, shouldn't GetAsyncKeyState work for what he's trying to do. Since if both keys are down, one had to be pressed first, I would think this should work. Pseudocode:
if nChar == VK_LEFT { If GetAsyncKeyState(VK_DOWN) DoStuff(); } if nChar == VK_DOWN { If GetAsyncKeyState(VK_LEFT) DoStuff(); }
My articles www.stillwaterexpress.com BlackDice
-
since they are handled one at a time, shouldn't GetAsyncKeyState work for what he's trying to do. Since if both keys are down, one had to be pressed first, I would think this should work. Pseudocode:
if nChar == VK_LEFT { If GetAsyncKeyState(VK_DOWN) DoStuff(); } if nChar == VK_DOWN { If GetAsyncKeyState(VK_LEFT) DoStuff(); }
My articles www.stillwaterexpress.com BlackDice
BlackDice wrote: since they are handled one at a time, shouldn't GetAsyncKeyState work for what he's trying to do. Having never used that function, I do not know. Unlike the Ctrl, Alt, Windows, and Shift keys, I don't think the keyboard is going to let both the left and down arrows be pressed simultaneously. I've not verified this, however, other than trying it in a text editor. Whichever key happened to get pressed first is the direction in which the cursor moves.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
-
BlackDice wrote: since they are handled one at a time, shouldn't GetAsyncKeyState work for what he's trying to do. Having never used that function, I do not know. Unlike the Ctrl, Alt, Windows, and Shift keys, I don't think the keyboard is going to let both the left and down arrows be pressed simultaneously. I've not verified this, however, other than trying it in a text editor. Whichever key happened to get pressed first is the direction in which the cursor moves.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
for a while, I was dabbling in DirectX game programming fundamentals. This was a simple way of making an object move diagonally by pressing a vertical and horizontal arrow key at the same time. I know that it works in that situation, so I think it should work for this one also My articles www.stillwaterexpress.com BlackDice
-
for a while, I was dabbling in DirectX game programming fundamentals. This was a simple way of making an object move diagonally by pressing a vertical and horizontal arrow key at the same time. I know that it works in that situation, so I think it should work for this one also My articles www.stillwaterexpress.com BlackDice
I wonder if that is specific to DirectInput (which was apparently not an option for the OP), or if it would apply to all of Windows.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
-
I wonder if that is specific to DirectInput (which was apparently not an option for the OP), or if it would apply to all of Windows.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
Well, I wasn't actually using DirectInput. But this was more a Windows program with the keydown being handled in the message loop. Something like this:
if(GetAsyncKeyState(VK_LEFT) m_object.left -= .01. if(GetAsyncKeyState(VK_RIGHT) m_object.left += .01. if(GetAsyncKeyState(VK_UP) m_object.top -= .01. if(GetAsyncKeyState(VK_DOWN) m_object.top += .01. DrawScene();
at any time if you check the GetAsyncKeyState() function (there's also an additional parameter that escapes me right now), any key that is pressed will return true My articles www.stillwaterexpress.com BlackDice
-
try
GetAsyncKeyState()
My articles www.stillwaterexpress.com BlackDice -
On a uniprocessor machine, you won't be able to do this as messages are handled one at a time.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
Uniprocessor really has nothing to do with it. Yes, the message is sent one at a time to an application, but the same happens if it's multi-processor. The message the window gets is serialized because the message queue and a single threaded window proc make it that way. The keyboard interrupt is free to generate another scan code/send the next byte when the the interrupt handler sends the EOI (End Of Interrupt) control. This happens almost immediately after you've read the key scan code from the port. Then the key is put into the keyboard buffer and sent off to generate the message. While that is going on, the keyboard is still a hardware device that can interrupt a thread's processing (just like anything else) based on it's current IRQL. So, even on a single processor, the next key press could be retrieved and processed all before the application ever gets dispatched the first key. The only thing the multi-processor could do is if the first processor got caught on a disk I/O and is at high IRQL, the other processor could handle the next keyboard interrupt at the same time. However, after the Disk I/O was done the keyboard would have gone and done it's turn before the thread was allowed to reschedule to a lower IRQL anyway. The other funny thing is that actually one processor could be delievering the current key while the other one is processing the next, so it actually could make the situation worse since if it was single processor the hardware interrupt would definately interrupt the keystroke delivery while processing the other key. This is a minor detail though, processing a scan code is farily quick. Pressing multiple keys the keyboard ends up continously generating one of the keys usually, the last one pressed. So a series of keystrokes could be: (Make Code) UP (Make Code) DOWN (Make Code) DOWN (Make Code) DOWN (Break Code) UP (Break Code) DOWN So, even though both keys are pressed the second action is continous so depending on how the application handles this it could move the cursor up then continously down because the application doesn't track the UP key's state. The UP key never provided a break code (key unpress) yet. So, it depends on how the application tracks the keyboard state. There are also special keys, I don't remember if the keyboard itself handles these or it if was solely a process done by the BIOS, but as you know certain keys maintain a "shift" type state, such as Alt, Control and Shift. It's been a while since I wrote a keyboard filter driver though or