Re: how to prevent Gtk::Entry to "Pass on" key event?

[jody <jody xha gmail com>]

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
<kjell ahlstedt bredband net> 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 <yann leydier info> 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
>>>>> gtkmm-list gnome org
>>>>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>>>>
>>>>
>>>> _______________________________________________
>>>> gtkmm-list mailing list
>>>> gtkmm-list gnome org
>>>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>>
>> _______________________________________________
>> gtkmm-list mailing list
>> gtkmm-list gnome org
>> https://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>