I am trying to attach Commands to buttons. This method works for 'q' and 'm', but it is not working for 'p' character.
Using '-112' did not solve the problem either. using minus symbol works for arrow keys but not for 'p'.
addKeyListener(113, new CommandA(gameWorld)); // q
addKeyListener(109, new CommandB(gameWorld)); // m
addKeyListener(112, new CommandC(gameWorld)); // p - Not Working
pressing 'p' does nothing.
UPDATE
Found a workaround...
This won't work for you on the device anyway as most devices are touch devices. The virtual keyboards on such devices don't send these events anyway. The arrow keys send undocumented values which differ a lot and you should "theoretically" use the game key API and not the key API. But again this won't work on the devices most commonly used today.
The characters aren't just numbers. They are literally the character value (int)'p'. There is no special treatment for them but it's possible that something in the system is grabbing that specific character as it's commonly associated with a print shortcut.
Related
I bought a second keyboard, USB with 20 programmable keys. I'm using Windows.
The programming utility foresees using it for gaming, for macros, or as a number keypad, but I need it for another script - I don't want to duplicate keys I already have on my normal keyboard.
I notice that normal keycodes for the function keys F1-F12 are 112-123, but this utility offers me function keys F1-F20, presumably with codes 112-131. For my 20 extra keys, I'd like to use 124-143, as if they were F13-F32: I want to be able to recognize keys from the second keypad unambiguously. NumLock is 144, but there doesn't seem to be any codes in my range.
But is there a correct or better way to do this? I can't be the first person to want to add more keys to a keyboard.
I am trying to keep track of the pressed keys. I have glutIgnoreKeyRepeat(1) and I register the key events (down/up for normal and special) in an object that keeps track of the keys pressed (called the list of pressed keys from now on) so that I just check in my display function if a key is pressed by looking in that list.
The problem is with SHIFT: Different keys register as DOWN and UP (depending on whether SHIFT was pressed or not) for the same physical keyboard key (eg.
a and A, 1 and !, [ and { etc.)
Consider this (with {key1 key2} representing my list of pressed keys after the event):
initial state : {} no keys listed as pressed
SHIFT DOWN : {SHIFT}
a DOWN : {SHIFT A} (because SHIFT is still down, capital 'A' registers as the key down.
SHIFT UP: {A}
a UP: {A} (because SHIFT is not pressed, lower 'a' registers as the key up, so a is removed from the pressed key list (which actually doesn't exist), and A still remains)
final state: {A} even though no keys are still pressed on the keyboard.
For alpha keys I can solve this by adding/removing the lower case of the keys (a instead of A).
But what about 1 and ! or [ and {. glutGetModifiers doesn't help here. Or what if a key is pressed, the window looses focus, the key is released and the window gains focus again (there is no event to tell that the key was released when the windows lost focus)?
Is there a general solution to check if a key is pressed? (platform dependent solutions are ok, another library is not for me, but maybe for others who need to solve this)
What you want are the keycodes, the physical number of the key being pressed on the keyboard. These are different on Apple and PC keyboards, and can also be different on keyboards in other countries where the letters change positions.
Most programs don't care about keycodes, they want actual letters and modifier keys, so the system event handler provides a translation from keycode into the intended character/special key. GLUT is designed to be simple, portable, and cross-platform, so uses these routines.
If you're writing a game or simulator, just lowercasing everything is probably good enough. For that kind of high speed interaction, most players won't want to distinguish between 1 and !, or 2 and #. The Ins/Del and arrow key blocks (usually) don't have multiple symbols anyway, and the numeric keypad is too far away for most people to hold down a modifier key at the same time.
If you really, truly, need to track every key state, sorry GLUT won't work for you. On MacOS you ask the NSKeyEvent for the keycode, on MS Windows you use DirectX, on Linux you use the XKeyPress|ReleaseEvent keycode.
Hope this helps.
I want to create an accelerator for CTRL+A. I noticed that it doesn't work when you leave out FVIRTKEY, i.e. the following code snippet doesn't work:
a.fVirt = FCONTROL;
a.key = 'A';
a.cmd = IDM_ADD;
(just for completeness' sake: using 'a' instead of 'A' doesn't work either)
This, however, works fine:
a.fVirt = FCONTROL|FVIRTKEY;
a.key = 'A';
a.cmd = IDM_ADD;
Can somebody explain this behaviour? MSDN says that if FVIRTKEY isn't set, "key" is interpreted as a character code which I presume to be ASCII. But it doesn't work which leaves me somewhat puzzled.
Thanks!
The system translates certain Ctrl key combinations into ASCII control codes. The combination Ctrl+A is translated to the ASCII ctrl-A (SOH) character (ASCII value 0x01). This is the reason why your first snippet does not expose the desired behavior: It requires input that is impossible to enter. This is documented under Keyboard Input in the MSDN.
Also note that not providing the FVIRTKEY flag makes the specified key case-sensitive, i.e. 'a' and 'A' map to different input. It is usually desirable to use virtual key codes, to provide a consistent keyboard UI. The implications are explained under About Keyboard Accelerators - Accelerator Keystroke Assignments.
On different machines, in an OnKeyDown override, the e.Key values are not necessarily consistent. For instance, on my Mac running Win7-64 under Boot Camp, the backslash key is reported as Key.OemQuote and not Key.OemBackslash as one would expect, which makes no sense considering that's not even on the same key. On a co-worker's Dell, it's reported as something else entirely.
However, in both cases, the correct backslash character is appearing in a textbox when typing so the OS obviously somehow knows that's what character that key is tied to.
We're trying to determine if, given a keycode on a particular system, you can get the corresponding character, if any, which that key represents (assuming no modifiers are pressed.)
Note: I am already aware of the OnPreviewTextInput and OnTextInput events which deal with the characters that are typed, but that is not what I am asking.
I am specifically asking about a function that takes a KeyCode as a parameter and returns what character would be displayed on-screen if that key were to be pressed.
For instance, on my machine, the function would take Key.OemQuote and would return the backslash character. Passing in Key.Control would return null (since nothing actually appears when Control is pressed alone.)
Note: I've put up another question about dealing with the different key codes specifically that may look similar to this question, but this is a very specific separate question relating to a function that takes such a code and returns a character, so please do not mark this as a duplicate. It is not.
I think the answer in this thread applies.
Also check out MapVirtualKey
PInvoke
I'm trying to make a simple text editor with winapi, its working for simple letter, but its not with capital letter or shift key.
char keys[256];
int x = 0;
while (1)
{
for (x = 0; x <= 256; x++)
{
if (GetAsyncKeyState(x) == -32767)
{
char c[5];
GetKeyboardState(keys);
ToAscii(x, MapVirtualKey(x, 0), keys, c, 0);
putchar(c[0]);
}
}
}
The behaviors of keyboard input are far more complex than what you think. Your method doesn't work because:
GetAsyncKeyState can miss keys. What happens when the user hits a key between calls?
What happens when you hold down a key? What about keyboard repeat?
Most critically, your code assumes a 1:1 relationship between key and character. You don't have any mechanism to deal with combinations like shift / caps lock state, or dead keys.
It would be better if you tried to explain what you're trying to do, and you can get advice on the right way to approach it. Trying to re-invent the behaviors of such a fundamental input device is not likely to be the best approach.
GetAsyncKeyState is likely not the way to go here: the real way to make a text editor type control is to instead handle the WM_KEYDOWN and WM_CHAR messages. Windows will send these to your WndProc when your HWND has focus. This is the technique used by the Windows EDIT and RichEdit controls.
Use WM_KEYDOWN to handle the non-character keys - like arrows (VK_LEFT, VK_RIGHT), page up and so on; and use WM_CHAR for text characters. WM_KEYDOWN tells you the key pressed using a VK_ value, and doesn't take shift state into account; while WM_CHAR does take shift state, so gives you 'A' vs 'a' or '1' vs '!' as appropriate. (Note that you have to have TranslateMessage in your messsage loop for this to happen.)
Having said all that, an even easier/better thing to do is just use the existing Windows EDIT or RichEdit controls and let them do the work for you - there's rarely a good reason to reinvent the wheel - unless you're playing around for fun and learning Win32 perhaps. Writing a proper text editor is pretty complex; there's a lot of non-obvious stuff to consider, especially when you get into non-English text: you'd need to ensure it works correctly with right-to-left text (Arabic, Hebrew), works with IMEs which are used to enter Japanese and Chinese characters. And you have to ensure that your control is accessible to screenreaders so that users with visual impairments can still use the control. EDIT and RichEdit do all this for you.
The actual Notepad app, for example, is just a wrapper for an EDIT control; while WordPad just wraps a RichEdit control; both let the control do all the hard work, and just add the extra UI and file save/load functionality on top.
Try to call
GetKeyState(VK_CAPITAL);
before
GetKeyboardState(keys);