Re: Widget mask out clicks

[Chris Vine <chris cvine freeserve co uk>]

On Friday 05 January 2007 16:28, johnmb wrote:
> All I am trying to is to make the TreeView widget insensitive to mouse
> clicks.  I am putting together a touch sensitive screen application and
> peoples fingers are going to be too thick to reliably control the tree
> directly so I am using separate buttons at the bottom of the screen to
> navigate the tree.  I want to inhibit the mouse clicks on the tree itself
> to avoid accidental corruption of the cursor position by peoples fingers
> brushing against the screen as they move from one part of the screen to
> another.
>
> I tried unsetting Gdk::BUTTON_RELEASE_MASK also but to no avail.  There is
> something about having to overload the events themselves in the docs but I
> wasn't sure about which methods these referred to.  Have you done this
> yourself.

You can connect to the gtkmm signal proxies for the GDK events concerned with 
the second argument (the "after" argument) of false so that they are called 
before the default signal handler, and return true in the callback, which 
will stop further propagation of the event concerned.  You can also overload 
the equivalent protected virtual function equating to the signal and return 
true from that, which will also prevent event propagation if all works 
correctly, although I would prefer connecting directly to the signal proxy as 
mentioned above.  (I have a folk memory that on one or two occasions the 
protected virtual functions didn't quite do what I wanted when returning 
true.)

That is the only way to do it if you want dynamically to switch event handling 
on and off after the widget has been realised.  However, none of that should 
be necessary if you set the event bit mask correctly and you do so before the 
widget concerned is realised.

With raw (C) GDK/GTK+ you can also block the signal dynamically with the 
g_signal_handler_block()/g_signal_handler_unblock() functions, but to use 
that with gtkmm you would probably have to connect directly to the C 
(GObject) signal for the event because I don't think that the gtkmm signal 
proxies expose the underlying GObject signal handler id.

However, are you sure you are actually blocking events for the correct widget?  
It sounds as if you are not, but I don't know to any degree of detail how 
GtkTreeView propagates events between renderers to columns to tree views and 
the like.

Chris