From Audacity Wiki
Jump to: navigation, search

Summary Points

Our code intercepts keystrokes on WM_KEYDOWN. We convert from a keycode (platform specific) to unicode. That started failing for diacritics, Japanese IME input and special keyboards (Keyman) with the move from wx2.8.12 to wx.3.0.2. We've been urged to shift over to using WM_CHAR, i.e. a later stage in the processing.

The Bug Cluster

1778P4NEWCannot type diacritics into label text1778

History (Brief)


  • We maybe would make a little more headway using the existing code by using the wxWidgets function event.GetUnicodeKey() instead of ToUnicode(event.GetRawKeyCode(), 0, ks, ucode, 256, 0)
  • A proper fix entails using WM_CHAR.

Keyman Bug Tracker

Keyman Github Issue

"So the issue with label track edits is in Audacity. Label tracks don't use a standard Windows or wxWidgets edit control, and have instead a bunch of code to implement a basic text edit field. The root issue is in this code in CommandManager.cpp:

   // Convert the key down event to a unicode string.
   wxString GetUnicodeString(const wxKeyEvent & event)
      wxString chars;

#if defined(__WXMSW__)

      BYTE ks[256];
      WCHAR ucode[256];
      int res = ToUnicode(event.GetRawKeyCode(), 0, ks, ucode, 256, 0);
      if (res >= 1)
         chars.Append(ucode, res);

Audacity is handling WM_KEYDOWN events (these are wrapped in wxKeyEvent objects), and then calling ToUnicode to convert key events to Unicode characters. This isn't the right way to get character input on Windows. The ToUnicode function doesn't cover all Windows input cases, even for standard Windows keyboards and IMEs. Instead, Audacity should be accepting WM_CHAR events and processing these (MSDN)."

Keyboard Handling

We should be aware of the difference between:

  • WM_CHAR - the one we should be capturing. It's UTF16. Has bits for extended keyboards, e.g. can differentite right and left Ctrl keys.