wxGTK: How to avoid stealing accelerators from wxTextCtrl?
Vadim Zeitlin
We solved the problem of using some special key [combinations] such as Del
or Ctrl+[CVX] &c) as an accelerator while still allowing to use them in
wxTextCtrl under MSW some time ago. There, the control getting the key
event is asked about whether it's special for it first and accelerator
mapping is not used if its MSWShouldPreProcessMessage() returns false.
However the same problem still exists in wxGTK: if you set e.g. WXK_DELETE
as an accelerator, it will be always as such, even when wxTextCtrl has
focus, so deleting the characters in the controls with this key doesn't
work any more.
I'd like to do something similar to wxMSW solution in wxGTK as well but I
just don't see how: in wxMSW, we do the accelerator translation ourselves
by calling ::TranslateAccelerator() which allows us to insert our own code
before calling it. But in wxGTK "activate" signal for the menu item for
which the accelerator it set is generated by wxGTK itself directly from the
event loop, i.e. the stack trace looks like this (simplified):
wxMenuBase::SendEvent
menuitem_activate
... only GTK internal signal emission functions here ...
closure_accel_activate
gtk_accel_groups_activate
gtk_window_activate_key
gtk_window_key_press_event
... more GTK internal signal emission functions ...
gtk_widget_event_internal
gtk_propagate_event
gtk_main_do_event
gdk_event_dispatch
g_main_dispatch
g_main_context_iterate
g_main_loop_run
gtk_main
wxGUIEventLoop::Run
wxAppConsoleBase::MainLoop
wxAppConsoleBase::OnRun
wxAppBase::OnRun
MyApp::OnRun
wxEntry
wxEntry
main
Does anybody see where could we hook into this code with our check? Or any
other ideas about how could we let wxTextCtrl have these keys for its own
use? Would setting them as accelerators for it work perhaps? How do native
GTK+ programs deal with this?
Thanks in advance for any ideas,
VZ