I derived my own control from CEdit
and it behaves as I intend:
#define IsSHIFTpressed() ( (GetKeyState(VK_SHIFT) & (1 << (sizeof(SHORT)*8-1))) != 0 )
void CEditEx::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if (IsCTRLpressed() && nChar == 2)
{
// Do something
return;
}
if (IsCTRLpressed() && nChar == 9)
{
// Do something
return;
}
CEdit::OnChar(nChar, nRepCnt, nFlags);
}
However, I have two questions about how I am detecting the key press:
OnChar
without the need to use GetKeyState
?"b"
(2) and "i"
(9)? I only knew I needed to use those numeric values from when I debugged into the handler.As you have noted, the value of the nChar
argument to OnChar
for keyboard entries of Ctrl + "a letter" (independent of the case) will be the ASCII "control-key" values, 1 (for "a") thru 26 (for "z").
To answer your second point: a search through the <WinUser.h>
header file shows no VK_xxx
tokens for these; however, be aware that some of these control codes are used (by convention) for other actions: Ctrl+M (decimal 13) is equivalent to Return or Enter, and the header has #define VK_RETURN 0x0D
; further, for one of your specific cases, Ctrl+I (9) is the ASCII TAB
character, and the header, accordingly, has the #define VK_TAB 0x09
definition.
Although the Ctrl+B ASCII code (0x02) is much less used these days (STX
, or "Start of Text"), that value is used by Windows for the right mouse button (#define VK_RBUTTON 0x02
).
So, to answer your first point: Yes, you will need to make the GetKeyState(VK_CONTROL)
check! Without that, a right-click will likely give you a false Ctrl+B and the Tab key will give a false Ctrl+I.
Furthermore, though I have no 'hard evidence' other than your own investigations, I think that a right-click while the Control key is down will generate a different value for nChar
(i.e. not 2), and Ctrl+Tab will generate an nChar
different from that for Tab alone.