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
_______________________________________________
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list
