Re: how to prevent Gtk::Entry to "Pass on" key event?
- From: Kjell Ahlstedt <kjell ahlstedt bredband net>
- To: jody xha gmail com
- Cc: gtkmm-list gnome org
- Subject: Re: how to prevent Gtk::Entry to "Pass on" key event?
- Date: Wed, 20 Jun 2012 10:55:56 +0200
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]