Re: Why cursor keys are not longer reported in key press events
- From: Kjell Ahlstedt <kjellahlstedt gmail com>
- To: Klaus <lts-rudolph gmx de>
- Cc: gtkmm-list gnome org
- Subject: Re: Why cursor keys are not longer reported in key press events
- Date: Sat, 28 Mar 2020 10:34:36 +0100
On 2020-03-27 17:03, Klaus wrote:
Some research later:
Seems that build in event handler of Gtk::Window has changed behavior.
class MyWin: public Gtk::Window
{
bool on_key_press_event( GdkEventKey* event ) override
{
std::cout << "KeyPressEvent" << std::endl;
bool retval = Gtk::Window::on_key_press_event( event );
std::cout << "Retval from native win function:" << retval <<
std::endl;
return false;
}
};
As we see, if cursor keys are going into the function, retval is true
which stops following handlers to see the keys.
Every handler which was introduced with
"win.signal_key_press_event().connect" will not any longer executed.
That Gtk::Window "eats" the cursor keys is new. Compiled the same
program some weeks ago the cursor keys where also present in the later
on dynamically registered handlers.
OK, can workaround by simply overriding all the window handlers...
Regards
Klaus
This is normal behavior for event signals. The default handler can stop
further processing by returning true. It's described e.g. at
https://developer.gnome.org/gtkmm-tutorial/stable/sec-xeventsignals.html.en
https://developer.gnome.org/gtkmm-tutorial/stable/chapter-keyboardevents.html.en
You shall set the 'after' parameter to false in the call the connect().
https://developer.gnome.org/glibmm/stable/classGlib_1_1SignalProxy.html#a0bee9dba36374339ab19ec34f288613e
Kjell
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]