What’s wrong with TranslateMessage? Two things:
- It probably shouldn’t be in the message loop. Different windows do different things with character and keystroke messages. Performance is not an issue here nowadays. Having TranslateMessage in the message loop has resulted in awful things such as IsDialogMessage and TranslateAccelerator calls for every message that goes through the loop.
-
More importantly though, TranslateMessage really should return TRUE if the keystroke message generates characters. It should return FALSE in every other situation. Unfortunately, TranslateMessage currently returns TRUE for WM_*KEYDOWN messages, even if no characters are generated by the keystroke (think F2 or Ctrl or up-arrow or Ctrl+Shift+X). This means that application developers have no way of knowing if the key can be safely used as a shortcut key, or should be ignored because a WM_CHAR or similar is on its way to insert into the current focus.
This in turn means that shortcut keys are typically processed (with TranslateAccelerator or a homegrown variety thereof) before TranslateMessage – and some characters are now inaccessible on some keyboard layouts.
The typical workaround is to add a hack for Ctrl+Alt (AltGr). Yuck. And that doesn’t solve other supported combinations such as Ctrl+Shift.
So what’s the answer to these problems? TranslateMessageEx?