I've been having some trouble getting the correct code for incoming keystrokes on the console for shift+number characters. For example, using:
cki = Console.ReadKey(True)
Console.WriteLine("You pressed the '{0}' key.", cki.Key)
If I press shift+2, I'm hoping to get the ascii 64 (for the '#' character), but instead I get 50 (for the '2' character).
Now, I know you can get the modifiers for the key pressed, but that would mean I'd have to program all the special cases for keys like that, and that doesn't seem right.
I need this function, or something like unto it, because of its ability to read keys as they are pressed, without the need to press enter, otherwise I'd just use console.read. Surely I've missed something. Could anyone tell me what it is I've missed?
You're looking for the KeyChar property, which returns the actual character rather than the physical key pressed.
You may want to cast it to int.
It is pretty important to distinguish between keys and characters. The key is the same anywhere in the world, the one on the top row at the left. You can rely on that key always producing ConsoleKey.D2
The character is however very different, it greatly depends on the active keyboard layout. A Northern American user presses Shift+2. A French user presses AltGr+0. A German user presses AltGr+Q. A Spanish user presses AltGr+2. Etcetera.
If you care only about the key then use ConsoleKeyInfo.Key, you do so for all non-typing keys like the function keys for example. Perhaps the typical gaming WASD keys. If you care only about the character, like #, then use ConsoleKeyInfo.KeyChar.
Related
In my game, the user can set a key to open the game-console.
I want to show an info during the game to the user, that they can open the console by pressing the key, they've set before.
For example:
The default key for the console is f1. Then it should show:
Press F1 to open Console
If the user sets the C key, it should write:
Press C to open Console
But i don't find any way to write down the key, the user set before, by code.
Edit:
I'm sorry that it wasn't that clear what i mean.
I added a screenshot of the Input-Configuration (which is the default Unity Input-Configuration).
In this Configuration the user can set a key for OpenConsole by double clicking on f1 (in the Primary row).
In Unity i can check if a specific Button is pressed like this:
if (Input.GetButtonDown("OpenConsole"))
{
...
}
But what i want is, that i can show the user which key they have chosen for OpenConsole. Something like this:
text.text = "Press the " + WhateverTheUserSet + " Key to open the Console!";
Okay, your question isn't clear as to how the default / redefined key is set / changed by the user but I'll give two solutions based on two scenarios:
Scenario 1: Assumes you are asking the user what key to use via an onscreen "Redefine Key" page.
In this situation, you will probably use something along the lines of Console.ReadKey() where you are capturing the user's keyboard press. You end up with a key code which could be one of around 100 keys on a keyboard. You will need to store internally a mapping between keycode and "text". If they user had pressed F1 and this is keycode (say 232) then you will use the mapping to give you the string "F1" which is what you display on screen. You would store the keycode in config for use in the game and for peristance between launches of the game.
Scenario 2: Assumes the user edits a config file and sets the value in there.
In this situation, you need the mapping going the other way. If the config file includes (by default):
ConsoleKey=F1
Then you need a similar internally stored mapping but in the other direction. If the user changes the value to "A" then this would need to map to a keycode (e.g. 65). The user can change the config file and the mapping will tell the user what key to detect in game. You can display the same text as in the config file for your on-screen "info".
If you can be clearer in how you are intending to implement this then we can provide a clearer answer.
Unfortunately, Unity doesn't have a way to check which keys are assigned from the input manager. If you need more control, you'd need to implement your own key mapping solution.
I use the namespace Windows.Forms.Keys
I would like to be able to catch and use some special like characters like é,è,à,ç, but when the program fire the event KeyDown, the KeyEventArg just return me the value "D1" to "D9".
What could I do to get the real char associated to these keys ?
Short answer: use KeyPress instead of KeyDown.
KeyDown is really designed to work with the physical layout of the keyboard (well, the logical layout of the physica... forget it :D). This is very different from the character that given physical key represents.
On the other hand KeyPress is all about characters being input from the keyboard, rather than keys being pressed, really. Note how KeyPress supports features like AltGr + someKey and char repetition etc.
If you really need to use KeyDown/KeyUp, you'll have to emulate the way windows keyboard system works to determine the char to output (for example, if you're making a keyboard mapping screen for a game or something like that). You can use the ToAscii WinAPI method (https://msdn.microsoft.com/en-us/library/ms646316.aspx).
Apart from that, you still have to understand the meaning of the key combinations - for example, on my keyboard, if I press 1, I get +. If I press Shift+1, I get 1. If I press AltGr + 1, I get !. Which of those do you care about? Maybe Shift + 1 should be interpreted as 1 (what KeyPress does). Maybe it should be interpreted as Shift + 1 (the easiest, you already have that). And maybe it should be interpreted as Shift + +, the way it's usually used for hotkey bindings or keyboard mappings in games.
It should be pretty obvious by now that this is actually far from trivial. You need some mechanism to interpret the "raw" input data - and different interpretations make different sense for different initial conditions. You're basically asking for a mixed approach between the two obvious options - you're mixing virtual keys and "real" characters.
I am trying to use the Sendkeys class to send a SHIFT key. But it doesn't allow for SHIFT. Only BACKSPACE or ENTER or basically anything but SHIFT. I need a way to send shift keys, like, Sendkeys.Send({SHIFT});
Is there a way to do this? Is there another way to send SHIFTs?
%() sends just the Alt command. So I assume that +() will send just the shift key. However I cannot think of a way to test this, since the shift key does nothing by itself. pressing shift 5 times normally prompts if you want to turn on sticky keys, but +()+()+()+()+() does not prompt for sticky keys.
Read the senction just after it explains how to send F1 to F12: https://msdn.microsoft.com/en-us/library/office/gg278655.aspx
%A = Alt+A
%(AE) = Alt+A+E
%()AE = ALT,A,E
In the same way that the question Sending “ENTER” key through serial port
how can i send the "ARROW key" through the serial port? Most particuly the UP arrow key.
Cursor keys are a relatively new feature of keyboards. They didn't yet exist at the time the ASCII codes were chosen. Which was largely based on the capabilities of teletypes that were used at that time. Like the widely used ASR-33, its keyboard layout looked like this:
No cursor keys. Note how line-feed was a separate key back then, '\n' in ASCII. Easier to get to and affecting the choice for the line-end control character in Unix. The Return key was the equivalent of the Enter key on a modern keyboard, '\r' in ASCII.
So there are no standard codes to pick for the cursor keys. You'll have to encode them yourself. ANSI escape codes were a common standard. Emulation of the DEC VT-52 and VT-100 were very common as well.
Since ARROW keys are scan codes (not defined in ASCII table), it is necessary to send a sequence of bytes to represent arrow keys (See https://en.wikipedia.org/wiki/ANSI_escape_code for details). Unfortunately, this sequence may vary between different platforms and targets, so you need to experiment for what is correct for your target.
Tested on a Ubuntu 16.04 target from a serial console on Windows, the ARROW UP sequence is three bytes (0x1b, 0x5b, 0x41), or on keyboard: ‘Esc’ ‘[‘ ‘A’
I have a little C# console application that reads a key and checks to see if the key was a question mark:
ConsoleKeyInfo ki = System.Console.ReadKey();
if (ki.ConsoleKey.Oem2) // Do something
I arrived at Oem2 by seeing what value is actually assigned in the debugger, because there is no ConsoleKey code for question mark.
Now I could certainly use ki.KeyChar instead, but the application also needs to respond to certain keys (e.g. media keys) that do not map to characters. It feels inelegant to check both ConsoleKey and KeyChar to determine which key has in fact been pressed. On the other hand, it does not feel safe to rely on Oem2 to always map to ? in all circumstances and regions.
Is it best practice to check both properties to determine which key was in fact pressed?
Any insight into why ConsoleKeyInfo was designed this way is appreciated.
In this case, you will have to check KeyChar == '?'. From MSDN:
Oem2: The OEM 2 key (OEM specific).
So you're just getting lucky in that it happens to be a ? on your equipment.
The ConsoleKeyInfo structure provides KeyChar (a Char value) as well as Modifiers (an enumeration) to help you decide what keys the user had pressed.
I think you should consider what happens when someone has different keyboard layout.
If you want to check for “the key with question mark on my computer”, then use ConsoleKey. But that's probably not a good idea and you should probably adhere to the user's settings and use KeyChar.
But for keys that don't map to to characters (and the user can't remap them by using different keyboard layout), you have to use ConsoleKey.
So, yes, I think you should check both properties in this case.
I guess the reason for this design is that Console.ReadKey() relies on a native function (ReadConsoleInput) that returns an array of KEY_EVENT_RECORD structures in case of a keypress, where each key event has an ASCII/Unicode character representation and a virtual key code. Notice the VK_OEM_2 in my previous link - this is where the ConsoleKey.Oem2 value comes from.