Opened 8 years ago

Closed 8 years ago

#13558 closed defect (fixed)

Windows KeyDown event: wxKeyEvent contents have changed from 2.9.1 to 2.9.2

Reported by: daumling Owned by:
Priority: normal Milestone: 2.9.3
Component: base Version: 2.9.2
Keywords: Windows wxKeyEvent Cc:
Blocked By: Blocking:
Patch: no

Description

In 2.9.1, the m_uniChar field contained the character code also for non-Unicode characters (like 0x0D). This field is now zero. I had to change my CR key detection to use GetKeyCode() instead of GetUnicodeKey(), which worked in 2.9.1.

For a German keyboard, the <> keys (VK_OEM_102) are not mapped, and the keycode is 0. Therefore, these keys cannot be entered into Scintilla.

There seems to be a missing MapVirtualKey() call to map Windows virtual keys to Latin-1 keys. I added the call in the OnKeyDown handlers in a subclass of wxStyledTextCtrl to enable input of <> on German keyboards.

Change History (6)

comment:1 Changed 8 years ago by neis

See also #13409.

comment:2 Changed 8 years ago by vadz

  • Milestone changed from 2.9.2 to 2.9.3
  • Status changed from new to confirmed

Note to self: the other bug (#13409) had useful instructions about reproducing the problem without the German keyboard.

Concerning 0x0D: we could restore this, I guess, but I'm not sure if it makes sense to make exceptions for it. In this case we'd probably need to always set m_unicodeKey to m_keyCode for the entire ISO8859-1 range. Any thoughts about desirability (or not) of this?

comment:3 follow-up: Changed 8 years ago by daumling

IMHO, ISO8859-1 is part of Unicode, so m_unicodeKey should reflect m_keyCode if the latter field contains a valid ISO8859-1 key. It would be confusing to set m_unicodeKey to 0 for key codes that people would expect to be part of the Unicode character set.

BTW: What about non-BMP key codes? At some point, it may be helpful to support Unicode values >= 0x10000, especially for Far Eastern languages. If not possible, the method name could be changed to something like GetUcs2Key() (ah, I know it is ugly, but it would prevent confusion).

comment:4 in reply to: ↑ 3 Changed 8 years ago by vadz

Replying to daumling:

IMHO, ISO8859-1 is part of Unicode, so m_unicodeKey should reflect m_keyCode if the latter field contains a valid ISO8859-1 key.

Yes, this is actually done in other places and the fact that it wasn't done for WXK_RETURN was really just a bug.

BTW: What about non-BMP key codes?

I think we'd need to change GetUnicodeKey() return value to wxUniChar to support this properly. And, of course, implement actually getting such events, i.e. start using WM_UNICHAR instead of WM_CHAR.

comment:5 Changed 8 years ago by VZ

(In [69843]) Set Unicode key code correctly for key events for WXK_RETURN in wxMSW.

WXK_RETURN is an ASCII character so return it from wxKeyEvent::GetUnicodeKey()
for EVT_KEY_{DOWN,UP} events, especially as it was already done for EVT_CHAR
ones.

See #13558.

comment:6 Changed 8 years ago by VZ

  • Resolution set to fixed
  • Status changed from confirmed to closed

(In [69844]) Add support for VK_OEM_102 key under wxMSW.

This is the "<>|" key on German keyboard and is also used in many other
layouts so failing to handle it resulted in not receiving EVT_KEY_XXX events
for these keys in wxWidgets programs.

Closes #13558.

Note: See TracTickets for help on using tickets.