Re: Event Propagation problem

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

I think this is work trying:

bool
Toolbox::on_key_press_event(GdkEventKey* event)
{
  Gtk::Widget* focused_widget = get_focus();

  if (focused_widget_shall_override_accelerators(focused_widget))
    return focused_widget->event((GdkEvent*)event);

  return Gtk::Window::on_key_press_event(event);
}

Or like so, depending on what you want to do if the focused widget does 
not handle the event:

bool
Toolbox::on_key_press_event(GdkEventKey* event)
{
  Gtk::Widget* focused_widget = get_focus();

  if (focused_widget_shall_override_accelerators(focused_widget))
  {
    if (focused_widget->event((GdkEvent*)event))
      return true;
  }

  return Gtk::Window::on_key_press_event(event);
}


2012-01-14 13:24, Carlos Lopez Gonzalez skrev:
> Regarding to the child with the focus, there is one member on Widget class that returns the focused child or 0 if none focused.Widget* Gtk::Window::get_focus()
> That's good, I have a pointer to the focused child widget.
> How do I make it handle the key event signal if its default signal handler is protected? Is there other way to make the event handled by the widget?
> Thanks!
> Carlos
>
>
>
>
> ----- Mensaje original -----
> De: Carlos Lopez Gonzalez<carloslopezgonzalez yahoo es>
> Para: Kjell Ahlstedt<kjell ahlstedt bredband net>
> CC: lecas malecas<darkiiiiii gmail com>; "gtkmm-list gnome org"<gtkmm-list gnome org>
> Enviado: sábado 14 de enero de 2012 12:38
> Asunto: Re: Event Propagation problem
>
> Hi Kjell, you're absolutely right. Removing the two signal event connections calls from the Toolbox does the job perfectly.
> Also thanks for the links for the documentation on signals. Still need learning a lot! :)
>
> As you have noticed, the way I've researched whether one child widget of the Toolbox is on edition mode (and so, the key events can be handled and so stopped its propagation when applicable), is looking to the widget's focus status. In this case (the Toolbox) there is only one possibly conflictive widget (one spinbutton), the other are just buttons that doesn't interfere with the key accelerators. 
> My application has one toolbox (the top level window), one or more document windows and two helper windows with deep nested hierarchy of widgets (notebooks, H(V)Box, Treeviews and cellrenderers and celleditable widgets).
>
> As you can imagine the work of look up whether a deep widget is focused to call its override key signal handler might be insane.
>
> Is there other way to ask one window that returns the current child focused widget? Do I need to recursively look all the children and ask if they are focused or any of its children is?
> Thanks in advance
> Carlos
>
>
> ________________________________
> De: Kjell Ahlstedt<kjell ahlstedt bredband net>
> Para: Carlos Lopez Gonzalez<carloslopezgonzalez yahoo es>
> CC: lecas malecas<darkiiiiii gmail com>; "gtkmm-list gnome org"<gtkmm-list gnome org>
> Enviado: sábado 14 de enero de 2012 11:01
> Asunto: Re: Event Propagation problem
>
>
> Hi Carlos,
>
> Glib::SignalProxy1<...>  with its connect() method is
>      documented here:
> http://developer.gnome.org/glibmm/unstable/classGlib_1_1SignalProxy1.html
>
> When I look at your code I notice that my previous long reply was
>      not long enough. I had forgotten the possibility to override default
>      signal handlers, as described here:
> http://developer.gnome.org/gtkmm-tutorial/stable/sec-overriding-default-signal-handlers.html.en
>
> That's actually what you have done, when you have overridden the
>      virtual functions Gtk::Widget::on_key_press_event() and
>      on_key_release_event() in Toolbox. The calls to
>      signal_key_[press|release]_event().connect() in Toolbox are
>      unnecessary, and I recommend that you delete them. I think that your
>      Toolbox::on_key_[press|release]_event() functions are called twice,
>      when they return false. (Once because of the signal handlers you
>      connect, then again (if false is returned) because they are part of
>      the default signal handling.) No disaster follows, but it's
>      unnecessary.
>
> Kjell