CodeSOD: The Wrong Kind of Character

Today's code, at first, just looks like using literals instead of constants. Austin sends us this C#, from an older Windows Forms application: if (e.KeyChar == (char)4) { // is it a ^D? e.Handled = true; DoStuff(); } else if (e.KeyChar == (char)7) { // is it a ^g? e.Handled = true; DoOtherStuff(); } else if (e.KeyChar == (char)Keys.Home) { e.Handled = true; SpecialGoToStart(); } else if (e.KeyChar == (char)Keys.End) { e.Handled = true; SpecialGoToEnd(); } Austin discovered this code when looking for a bug where some keyboard shortcuts didn't work. He made some incorrect assumptions about the code- first, that they were checking for a KeyDown or KeyUp event, a pretty normal way to check for keyboard shortcuts. Under that assumption, a developer would compare the KeyEventArgs.KeyCode property against an enum- something like e.KeyCode == Keys.D && Keys.Control, for a CTRL+D. That's clearly not what's happening here. No, here, they used the KeyPressEvent, which is meant to represent the act of typing. That gives you a KeyPressEventArgs with a KeyChar property- because again, it's meant to represent typing text not keyboard shortcuts. They used the wrong event type, as it won't tell them about modifier keys in use, or gracefully handle the home or end keys. KeyChar is the ASCII character code of the key press: which, in this case, CTRL+D is the "end of transmit" character in ASCII (4), and CTRL+G is the goddamn bell character (7). So those two branches work. But home and end don't have ASCII code points. They're not characters that show up in text. They get key codes, which represent the physical key pressed, not the character of text. So (char)Keys.Home isn't really a meaningful operation. But the enum is still a numeric value, so you can still turn it into a character- it just turns into a character that emphatically isn't the home key. It's the "$". And Keys.End turns into a "#". It wasn't very much work for Austin to move the event handler to the correct event type, and switch to using KeyCodes, which were both more correct and more readable. [Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.

Apr 29, 2025 - 15:00
 0  0
CodeSOD: The Wrong Kind of Character

Today's code, at first, just looks like using literals instead of constants. Austin sends us this C#, from an older Windows Forms application:

if (e.KeyChar == (char)4) {   // is it a ^D?
        e.Handled = true;
        DoStuff();
}
else if (e.KeyChar == (char)7) {   // is it a ^g?
        e.Handled = true;
        DoOtherStuff();
}
else if (e.KeyChar == (char)Keys.Home) {
        e.Handled = true;
        SpecialGoToStart();
}
else if (e.KeyChar == (char)Keys.End) {
        e.Handled = true;
        SpecialGoToEnd();
} 

Austin discovered this code when looking for a bug where some keyboard shortcuts didn't work. He made some incorrect assumptions about the code- first, that they were checking for a KeyDown or KeyUp event, a pretty normal way to check for keyboard shortcuts. Under that assumption, a developer would compare the KeyEventArgs.KeyCode property against an enum- something like e.KeyCode == Keys.D && Keys.Control, for a CTRL+D. That's clearly not what's happening here.

No, here, they used the KeyPressEvent, which is meant to represent the act of typing. That gives you a KeyPressEventArgs with a KeyChar property- because again, it's meant to represent typing text not keyboard shortcuts. They used the wrong event type, as it won't tell them about modifier keys in use, or gracefully handle the home or end keys. KeyChar is the ASCII character code of the key press: which, in this case, CTRL+D is the "end of transmit" character in ASCII (4), and CTRL+G is the goddamn bell character (7). So those two branches work.

But home and end don't have ASCII code points. They're not characters that show up in text. They get key codes, which represent the physical key pressed, not the character of text. So (char)Keys.Home isn't really a meaningful operation. But the enum is still a numeric value, so you can still turn it into a character- it just turns into a character that emphatically isn't the home key. It's the "$". And Keys.End turns into a "#".

It wasn't very much work for Austin to move the event handler to the correct event type, and switch to using KeyCodes, which were both more correct and more readable.

[Advertisement] Keep all your packages and Docker containers in one place, scan for vulnerabilities, and control who can access different feeds. ProGet installs in minutes and has a powerful free version with a lot of great features that you can upgrade when ready.Learn more.

What's Your Reaction?

like

dislike

love

funny

angry

sad

wow