Comment 15 for bug 1803556

@Seth,
the root issue (on Windows) is the fact any accelerator key (or a hotkey added to a menuitem as accelerator) in the main menubar has the priority to any other window.

It is captured by the wxEVT_CHAR_HOOK event handler of parent windows.
Therefore if a menuitem (in the main menu, always activated) captures the key code of the wxEVT_CHAR_HOOK, the corresponding wxEVT_CHAR is never fired on Windows.

This issue is usually noticed when "printable" keys are used as accelerators.
(Not printable keys like Ctrl+xx or alt+xx are captured, but you never use them in wxTextCtrl so do not see this issue)

And if you capture this event (do not skip it), the wxEVT_CHAR is not fired, and the wxTextCtrl never receive a wxEVT_CHAR event.

Note also, for the same key of the keyboard, the key code returned by wxEVT_CHAR_HOOK event and wxEVT_CHAR event are not the same code.
This issue is not specific to the wxTextCtrl filter: this is a problem for all our hotkey management, and it does not depend on the canvas type.