Hi Kjell thank you for your reply When i omit the 'false' from the connect of IMWin::press_action, the keys are indeed not passed on (even without connecting to the Entry's signal_key_press_event()) With this simple configuration i see that the Entry passes on "special keys" such as 'ctrl', 'shift', 'alt' and 'tab' to my press_action(), while swallowing all normal keys and the 'Enter' key as well.
That's why i had the 'true' in the connect. That way press_action received the enter-event and could react appropriately (but on the other hand also reacted to the key 'f', for example, when it should not) Connecting to the Entry's signal_key_press_event() with an 'always-true-function' has the disadvantage that it also destroys tabs so you can't nicely change between the widgets any more So if there is no way to get a Gdk_Return from a Entry, i guess i'll have to to do some ugliness (catch all key events first, and if my entry has the focus, ill call the appropriate function; otherwise (no focus) i check for 'f' etc.etc) Thank You Jody On Wed, Jun 20, 2012 at 10:55 AM, Kjell Ahlstedt <[email protected]> wrote: > There is a section on event propagation in the gtkmm tutorial > http://developer.gnome.org/gtkmm-tutorial/stable/sec-keyboardevents-propagation.html.en > > There you can also find a small program that you can compile and experiment > with. > > Yann is right in that you need to connect to the Entry's > signal_key_press_event() and always return true from that signal handler. It > will stop the event from propagating to the enclosing window. But you have > connected IMWin::press_action() with the parameter after=false, which means > that it will be called before any of the Entry's signal handlers. > > If you remove 'false' in the call to connect() and connect to > m_entry.signal_key_press_event(), your program will work as you want when > the Entry has keyboard focus. But I suppose you added after=false for a good > reason. Are there other widgets in your window that consume key presses and > don't let them propagate to the enclosing window, although you want to > handle them in IMWin::press_action()? If so, you probably must keep > after=false, and test which widget has keyboard focus. > > bool IMWin::press_action(GdkEventKey *e) { > if (m_entry.has_focus()) > return false; > ...... > > In this case there is no need to connect to > m_entry.signal_key_press_event(). > > Kjell > > 2012-06-20 09:38, Yann Leydier skrev: > >> The keypress event has a return value that tells if the signal must be >> propagated: >> >> http://developer.gnome.org/gtk/stable/GtkWidget.html#GtkWidget-key-press-event >> >> I hope this means that it can help to tell the entry not to propagate the >> signal to the window. This should be something like adding : >> >> next_file_entry.signal_key_press_event().connect(sigc::mem_fun(this, >> &TWin::no_key_propagate)); >> >> bool TWin::no_key_propagate(GdkEventKey*) >> { >> return true; >> } >> >> If this does not work, then we'll have to conclude that Gtk's doc is >> cryptic on this point… >> >> yann >> >> On 20/06/12 09:23, jody wrote: >>> >>> Hi Yann >>> >>> I'm not sure i exactlyx understand what you mean by "connect to the >>> entry's signal". >>> >>> In my window's constructor i have: >>> signal_key_press_event().connect(sigc::mem_fun(*this, >>> &IMWin::press_action), false); >>> >>> where press_action method is: >>> >>> bool IMWin::press_action(GdkEventKey *e) { >>> bool bReturn = false; >>> // call appropriate button if return is pressed >>> if (e->keyval == GDK_Return) { >>> if (m_txtColorTable.has_focus() || m_butColorBrowse.has_focus()) >>> { >>> on_button_color_table_clicked(); >>> } else if (m_txtDataFile.has_focus() || >>> m_butDataBrowse.has_focus()) { >>> on_button_load_data_clicked(); >>> } >>> bReturn = true;; >>> } else if (e->keyval == GDK_f) { >>> m_Image->flip(); >>> } >>> return bReturn; >>> } >>> >>> Jody >>> >>> >>> On Wed, Jun 20, 2012 at 8:47 AM, Yann Leydier <[email protected]> wrote: >>>> >>>> Hi, >>>> >>>> did you try to connect to the entry's signal and just return "true" so >>>> that >>>> the event is not transmitted any further? >>>> >>>> yann >>>> >>>> >>>> On 20/06/12 08:40, jody wrote: >>>>> >>>>> >>>>> Hi >>>>> I have an application where i use keyboard events ( with >>>>> signal_key_press_event().connect() ) to >>>>> control some simple actions nan image which is displayed (e.g. >>>>> flipping it when 'f' is pressed) >>>>> I also have a Gtk::Entry to type in the name of then next file to be >>>>> loaded. >>>>> >>>>> But whenever i type the key 'f' in the Gtk::Entry, the image is >>>>> flipped (and the character 'f' is written in the Gtk::Entry), >>>>> i.e. the key event has been used by by the Gtk::Entry and then been >>>>> passed on to the containing window. >>>>> >>>>> Is there a way to tell the entry to "destroy" the key press event >>>>> after using it? >>>>> >>>>> Thank You >>>>> Jody >>>>> _______________________________________________ >>>>> gtkmm-list mailing list >>>>> [email protected] >>>>> https://mail.gnome.org/mailman/listinfo/gtkmm-list >>>>> >>>> >>>> _______________________________________________ >>>> gtkmm-list mailing list >>>> [email protected] >>>> https://mail.gnome.org/mailman/listinfo/gtkmm-list >> >> >> _______________________________________________ >> gtkmm-list mailing list >> [email protected] >> https://mail.gnome.org/mailman/listinfo/gtkmm-list >> > _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
