GetKeyState C++

How can i find the key state of individual characters/numbers?
I guess what i mean is i need some help understanding VK and the hexedecimal pointer.
Anyone care to explain? thanks alot!

Code:

---

#include <iostream>
#include  <windows.h>

using namespace std;

int main()
{
while(1)
{
    if(GetKeyState(VK_CONTROL) & 0x80)
    {
        cout<<"hey"<<endl;
    }
       
    // continue looping regardless, without waiting for any input.
}

system("pause");
return 0;
}

---

I guess what i mean is instead of just using VK_CONTROL i'd like to be able to use
VK_KEY_A
or
VK_KEY_L etc...
but i can't get them to work.
what am i doing wrong?

Well, first & 0x80 is not a hexidecimal pointer. In this case & is acting as a binary AND.

Other than that I can't help, I don't know windows.

Try 'A' ....'Z' in place of VK_KEY_A....VK_KEY_A.

thanks a lot!
now i have run into another problem.
everytime i press my key (a)
it runs the command like 100 times.
How can i make it only run once per evertime a is pressed?
thanks.

Quote:

---

Originally Posted by Jameslat

thanks a lot!
now i have run into another problem.
everytime i press my key (a)
it runs the command like 100 times.
How can i make it only run once per evertime a is pressed?
thanks.

---

You're in the wrong forum. There's a special forum for windows issues called C++ and WinAPI.

Quote:

---

Originally Posted by Jameslat

thanks a lot!
now i have run into another problem.
everytime i press my key (a)
it runs the command like 100 times.
How can i make it only run once per evertime a is pressed?
thanks.

---

"sleep(10)" to add a 10ms pause between each iteration. That's just one solution. More advanced solutions would be to use keyboard hooks and notifications, but that's a whole other level.

Depending on your needs though, the program called AutoHotKey could be what you are looking for.

I'll check out autohotkey :)
but what are these keyboard hooks?

Could you put the returned by GetKeyState() into a variable, then compare the next GetKeyState() with that variable and do something only when they are different?

That is a good idea.

I am running into some errors tho.
How should i best put it into a varible?

Something along the lines of this, note that I have not compiled or run it though.

Code:

---

#include <iostream>
#include  <windows.h>

using namespace std;

int main()
{
        SHORT last = 0;
while(1)
{
    if(last != (last = (GetKeyState(VK_CONTROL) & 0x80)))
    {
        cout<<"hey"<<endl;
    }
       
    // continue looping regardless, without waiting for any input.
}

system("pause");
return 0;
}

---

Quote:

---

Originally Posted by Jameslat

now i have run into another problem.
everytime i press my key (a)
it runs the command like 100 times.
How can i make it only run once per evertime a is pressed?

---

if you want to capture keys from the keyboard, do this with a keyboard hook

Code:

---

#include <iostream>
#include <windows.h>
 
using namespace std;
HHOOK hooked = 0;
 
LRESULT CALLBACK LowLevelKeyboardProc( int nCode, WPARAM wParam, LPARAM lParam)
{
    KBDLLHOOKSTRUCT* ABoutKeyboard = (KBDLLHOOKSTRUCT*)lParam;
 
    cout << "Recieved key" << ABoutKeyboard->vkCode << endl;
 
    return CallNextHookEx ( hooked, nCode , wParam, lParam );
}
 
int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nCmdShow)
{
 
    hooked = SetWindowsHookEx(WH_KEYBOARD_LL, &LowLevelKeyboardProc, hThisInstance, NULL);
    if (hooked == NULL)
    {
        cout << "Error" << endl;
        return 1;
    }
 
    MSG messages;
 
    while (GetMessage (&messages, NULL, 0, 0))
    {
        TranslateMessage(&messages);
        DispatchMessage(&messages);
    }
 
    return messages.wParam;
}

---

Quote:

---

Originally Posted by jeron

if(last != (last = (GetKeyState(VK_CONTROL) & 0x80)))[/code]

---

This, while fancy, is undefined behavior. C++ does not guarantee which side of operator!= is evaluated first. The right side could be evaluated first, making the condition always true.

Just take the time to create both a "current" and "previous" variable. The execution cost is virtually null. The code is longer, but easier to read and with clearer intent.

Section 1.9 of the standard.

Quote:

---

This, while fancy, is undefined behavior. C++ does not guarantee which side of operator!= is evaluated first. The right side could be evaluated first, making the condition always true.

Just take the time to create both a "current" and "previous" variable. The execution cost is virtually null. The code is longer, but easier to read and with clearer intent.

Section 1.9 of the standard.

---

Excellent points!:thumb:

Quote:

---

Originally Posted by Jameslat

thanks a lot!
now i have run into another problem.
everytime i press my key (a)
it runs the command like 100 times.
How can i make it only run once per evertime a is pressed?
thanks.

---

You should be handling WM_KEYDOWN or WM_CHAR messages instead of calling GetKeyState in a loop.

Please Sir, what application except games is htat to need getkeystate ?

Quote:

---

Originally Posted by monarch_dodra

This, while fancy, is undefined behavior. C++ does not guarantee which side of operator!= is evaluated first. The right side could be evaluated first, making the condition always true.

Just take the time to create both a "current" and "previous" variable. The execution cost is virtually null. The code is longer, but easier to read and with clearer intent.

Section 1.9 of the standard.

---

correct me if I'm wrong, but this is not due to unspecified evaluation ordering; the behavior is undefined because he's independently accessing and modifying a variable between consecutive sequence points ( by independently, I mean that the modification does not depend on the access result ... I don't remember the exact standard wording :) ). More specifically, if "last" were of class type the expression would have defined behavior ( provided operator!=,= have too ) and supposing usual operator semantics would always evaluate to true.

Quote:

---

Originally Posted by superbonzo

correct me if I'm wrong, but this is not due to unspecified evaluation ordering; the behavior is undefined because he's independently accessing and modifying a variable between consecutive sequence points ( by independently, I mean that the modification does not depend on the access result ... I don't remember the exact standard wording :) ). More specifically, if "last" were of class type the expression would have defined behavior ( provided operator!=,= have too ) and supposing usual operator semantics would always evaluate to true.

---

That would also be correct.

I would say it is undefined for both these reasons.

Although one could argue they are closelly related, if not equivalent. If evaluation had defined order, then multiple evaluation between two consecutive sequence points would not be such a problem.

That and my explanation is probably easier understood for the un-initiated ;).

EDIT: I just read the rest of your post. I'm pretty sure this would still be undefined if last was of class type. I'm not sure I see what that would change in this context. Last is evaluated twice, one of which modifies its value.

Quote:

---

Originally Posted by monarch_dodra

I'm not sure I see what that would change in this context. Last is evaluated twice, one of which modifies its value.

---

operators for class types are equivalent to function evaluations that in turn introduce sequence points at the end of argument subexpressions.

So, if x has fundamental type then "x != ( x = 0 )" has two sequence points ( those at the beginning and at the end ), therefore there's no possible "ordering", it's simply an expression giving undefined behavior because x is modified and x is accessed and its value is not used in the modification of x.

Conversely, if x has class type then "x != ( x = 0 )" is equivalent to "x.operator!=( x.operator=(0) )" which has a sequence point for each argument. Therefore, supposing signatures "bool operator!=(const T&) const" and "T& operator=(const T&)" with usual semantics the evaluation has defined behavior.

Quote:

---

Originally Posted by superbonzo

operators for class types are equivalent to function evaluations that in turn introduce sequence points at the end of argument subexpressions.

So, if x has fundamental type then "x != ( x = 0 )" has two sequence points ( those at the beginning and at the end ), therefore there's no possible "ordering", it's simply an expression giving undefined behavior because x is modified and x is accessed and its value is not used in the modification of x.

Conversely, if x has class type then "x != ( x = 0 )" is equivalent to "x.operator!=( x.operator=(0) )" which has a sequence point for each argument. Therefore, supposing signatures "bool operator!=(const T&) const" and "T& operator=(const T&)" with usual semantics the evaluation has defined behavior.

---

Ok, I see what you mean.

While there are more sequence points, argument evaluation ordering is still undefined. The question though is does the argument evaluation ordering affect the result?

I think it largely depends on the signature of operator!=()

For example, if the signature is:

Code:

---

bool T::operator!=(const T&);
or
bool operator(const T&, const T&);

---

Then the behavior is defined, as the arguments passed are just too pointers that point to the same object. You are technically evaluating &last, and not the actual value of last.

If the signature is

Code:

---

bool operator(T, T)

---

Then you will run into trouble.

I personally don't like thinking in terms of "sequence points" because it is more obscure, and by following a simpler "arguments can be evaluated in any order" logic, you should be able to reach the same conclusion.

That said, I also feel you should avoid this kind of writing altogether. No need to make things dangerous and complicated for no reason.

Hi :)

Code:

---

#include <iostream>
#include <windows.h>
using namespace std;
     
int main()
{
    short key;
   
    while(1) // to infinity and beyond :p.
    {
        for(key=0; key<256; key++) // for the decimal values 0-255.
        {
            if(GetAsyncKeyState(key)== -32767) // -32767 is the keyboard interrupt.
            {
                cout<<char(key)<<" = "<<key<<endl;
            }
        }
    }
}

---

The GetKeyState function cannot be successfully called in a console program cause it needs an active message queue (Windows). See the while (GetMessage(...)) loop in Joeman's comment.

Quote:

---

Originally Posted by Joeman

int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nCmdShow)
{
...
MSG messages;

while (GetMessage (&messages, NULL, 0, 0))
{
TranslateMessage(&messages);
DispatchMessage(&messages);
}

return messages.wParam;
}[/code]

---

But if you have such a loop the GetKeyState isn't necessary cause you would handle the WM_KEYDOWN message directly in that loop or add a handler to the WinProc associated with your main window (which was invoked by DispatchMessage from the message loop).

The purpose of the GetKeyState function is to get additional information in a handler function of another message, e. g. if you have a function that handles a click on a button you might check with GetKeyState if the user has pressed the shift key. All that is part of GUI programming and is totally far off the way a console (main) program works. A GUI program runs an infinite message loop (finally broken by a WM_CLOSE or WM_QUIT message) and all additional things are reactive, i. e. are responses to messages read from queue.