• no (unregistered)

    this is why you frist rtfm

  • A nunny moose (unregistered)

    Keys.Home mapping to $ isn't the real issue.

    The problem is that such key presses are typically stored in the keyboard as a 0x00 + another character. So pressing Home would add 0x00 0x24 to the keyboard buffer. So the code could work assuming argument e has a property denoting a special key and the code would check the value said property.

  • (nodebb)

    Keyboards are actually pretty complicated. I could write a whole essay about scan codes, key codes, key modifiers, evolution in hardware abstraction from DOS to NT, but the simple gist is that you have the classic Windows key codes plus the classic DOS modifier flags to work with under .NET. And yes, those are correctly mapped for other platforms as well.

    So that is the reason why you a key code plus modifier flags in the key args as well for the key events for those wondering.

    https://learn.microsoft.com/en-us/dotnet/api/system.windows.forms.keyeventargs?view=windowsdesktop-9.0

  • Joey (unregistered)

    I vaguely remember there not being KeyCodes and KeyUp/KeyDown events in the original .NET frameworks, and you had to do funky stuff with the KeyChars in that event. This might be carry over from that era?

  • (nodebb) in reply to A nunny moose

    Yeah I wonder how that plays out with the screen KBs that all the cool kids use now.

  • Álvaro González (github) in reply to MaxiTB

    Yes, keyboards must be complicated for sure. Microsoft Teams hasn't been able to make some basic features work in non-US layouts, so what are the chances for a small development shop?

  • (nodebb)

    Why check for keyboard accelerators manually? It's obviously using Windows, and Windows has functions to automatically handle keyboard shortcuts in the Windows OS itself. in fact the application loop typically handles all that stuff and stuffs the keyboard shortcut events into the queue automatically so you don't even need to know how the command was entered.

  • Fa (unregistered)

    Ctrl-D "end of transmission" is really nice. When you don't feel like typing exit or quit in the terminal, just hit ctrl-D and you're out

  • Officer Johnny Holzkopf (unregistered) in reply to Fa

    Ctrl+D works for many programs that read from STDIN (i. e., use the when working interactively), not just shells (used in terminals). This is decades old and established knowledge, together with the "special keys" (0x00 0xNN) as they are processed from the keyboard buffer. Get off my lawn, I'm old and grumpy...

  • (nodebb) in reply to Joey

    In the original 1.0 framework Control didn't had key events but this was already added with the 1.1 patch, so it was like one year later.

    Before that you had to use Win32 Interop callbacks for those events, which was annoying because it required to actually handle scan codes and mask the flag value instead of having it nicely available as a standard type. However considering that most C# devs came from C++, it wasn't that big of an ask. The big wave of non-natively trained developers came a few years later.

    Under the hood it looks like this: https://github.com/dotnet/winforms/blob/62ebdb4b0d5cc7e163b8dc9331dc196e576bf162/src/System.Windows.Forms/src/System/Windows/Forms/Input/KeyEventArgs.cs

  • (nodebb) in reply to MaxiTB

    Keyboards are actually pretty complicated.

    PC keyboards are, indeed, substantially more complicated than anyone might think, even if you take into account their complicatedness, but in general keyboards can be pretty simple. In the simplest case, it's just a grid of switches that connect scan lines to sense lines when keys are pressed, coupled with some way of addressing the scan lines.

    Case in point: the TRS-80 Model III, which sacrificed 256 bytes of address space to be able to read the sense lines, with the CPU address bus providing the input to the scan lines (the keyboard was small enough in key count to be able to support an 8-by-8 grid). With that, it could inherently provide a limited version of 2-key rollover, but not more.

  • (nodebb) in reply to Steve_The_Cynic

    Yeah, totally. I still remember hacking for weeks to get a simple keypad working well with a micro controller. It's actually pretty tricky to get toggle behavior suppressed the right way and spoiler, you use another keypad of the same vendor and series and it's off again a bit.

    So while PC keyboards where basically the cheapest way to turn key presses into serial packages, it's actually easier to tackle switch behaviors on a hardware level than trying to get it right on a generic software level, at least if you want it to feel snappy and responsive.

  • sudgy (unregistered)

    As somebody who uses an alternate keyboard layout where the distinction makes a much larger difference, I have learned that developers are very bad at using the correct key pressed/text entered event. I feel like they get it wrong more often than they get it right.

  • (nodebb) in reply to Fa

    When you don't feel like typing exit or quit in the terminal, just hit ctrl-D and you're out

    There are people who don't use ctrl+D to logout?

    I sometimes get tripped up by this when (for whatever reason) I pop into the Windows command prompt for a bit. Finish what I'm doing, hit ctrl+D... oh yeah, I have to manually type out "exit" in this one, like a barbarian.

  • löchlein deluxe (unregistered) in reply to Scarlet_Manuka

    Yeah weird. Colleague litters logout and exit over root's shell history files like some troglodyte.

  • (nodebb) in reply to Fa

    Ctrl-D "end of transmission" is really nice. When you don't feel like typing exit or quit in the terminal, just hit ctrl-D and you're out

    Incorrect, at least as far as Unix-alike terminal based programs are concerned. Ordinarily, the terminal driver accumulates the characters you type in an internal buffer, until you hit the return key. It then sends the characters it has accumulated and a newline (ASCII 10) to the program. When it detects ctrl-d all it does is send the characters it has accumulated in the buffer to the program immediately without a newline. It does not terminate stdin.

    The reason that the program thinks end of file has been reached is that it is almost certainly blocked in a read() system call i.e. waiting for you to type something. When the terminal driver sends it characters, whether as a result of the return key being pressed or as a result of ctrl-d, the read() unblocks and the program processes whatever it has been sent. If you press ctrl-d immediately after pressing return, there will be no characters in the terminal driver's buffer and zero characters will be sent to the program. However, the read() will still unblock and the program will see a result of zero characters being sent. In Unix, by convention, this teams "end of file" and there program will act accordingly.

    You can see this by typing cat in the shell with no arguments. It will then echo back all the characters you send but only after you hit the return key. Except, if you type some characters and ctrl-d instead of return, cat will just echo the characters you typed back. It will not terminate and it will process any further characters you choose to type.

    Addendum 2025-05-03 08:06: cat will terminate if you hit return and then press ctrl-d because only then will cat receive an empty buffer from the terminal driver.

Leave a comment on “The Wrong Kind of Character”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article