RE: Correct signal handler to overload in a treeview to STOP the selection from changing

["Huston, Bob" <rhuston mitre org>]

Ok, I figured out a way to do what I needed. 

First off, based on a ptr from Bob Caryl I chased down a few things and
found if you overload on_move_cursor I could do exactly what I wanted
to do.
Detect PRIOR to the tree view changing the selection if I wanted to
allow it to
or not. However, this only  worked if you moved the selection using the
arrow
keys, it did not work by moving with the mouse. Based on this I figured
the 
smarts must be there, just I haven't found the right boolean handler
(need boolean
to return true/false based on whether I want the selection to change).
I then 
overloaded every message handler, set breaks on them all looking for
one to be
called prior to on_cursor_changed. Well none of them did.

I then figured all I really needed to do was to track the "current"
selection in
the tree, then in on_cursor_changed, decide if I want things to change
or not. 
If so, let it go through, if not, set the selection back to my saved
"current"
and return.  This worked better than I had hoped, I thought I would get
into a 
infinite loop due to me manually setting the selection back to what I
want, I thought
this would fire another call to my handler, it didn't.

Basically I am all set now, it sure would have been nice if there was a
mouse
version of on_move_cursor, but I got it working as needed in any event.

--Bob
 

-----Original Message-----
From: Bob Caryl [mailto:bob fis-cal com] 
Sent: Friday, February 03, 2006 6:41 AM
To: Huston, Bob
Cc: gtkmm-list gnome org
Subject: Re: Correct signal handler to overload in a treeview to STOP
the selection from changing

Huston, Bob wrote:

> I have a treeview derived class, in which when a branch in the tree
is 
> displayed I display a
> notebook derived class showing many GUI controls for information 
> gathering. When
> the user selects a different branch in the tree, I save off the 
> currently displayed notebook information
> and display a new notebook for the new branch that is selected.
>  
> I accomplish this by overloading the on_cursor_changed signal handler

> in the tree view class.
>  
> The issue I am having is that when I am switching notebooks being 
> displayed I validate any and all
> information on the current notebook, if the information is valid, I 
> want to warn the user via and keep the
> tree from switching views. 
>  
> I am not switching the notebooks when this occurs, however the tree
is 
> still switching which branch is selected.
>  
> My code basically is this:
>  
> void CMyTreeView::on_cursor_changed()
> {
>     // save/validate the current notebook:
>     if ( !SaveCurrentNotebook())
>         return;
>  
>     // put up the new notebook
>     .....
>     return Gtk::TreeView::on_cursor_changed();
> }
>  
> I need to know how to either return from this handler so that the 
> selection doesn't change, or a different handler
> to overload to do my processing prior to the selection change occurs.

> I thought that by not allowing the
> parent tree view class's version of on_cursor_changed to be called 
> that this would happen.
>  
> --Bob
>  
>
>----------------------------------------------------------------------
--
>
>_______________________________________________
>gtkmm-list mailing list
>gtkmm-list gnome org
>http://mail.gnome.org/mailman/listinfo/gtkmm-list
>  
>

Hey Bob,

I could not find a signal directly relating to the Gtk::TreeView to 
which you could connect in order to prevent the TreeView from changing 
rows in response to a mouse click (and remember, a row can also be 
changed with the arrow keys on the keyboard).  However, you might 
consider connecting to "Gtk::Main::signal_key_snooper" and looking for
a 
"GDK_BUTTON_PRESS" event (see GdkEventButton 
http://www.gtk.org/api/2.6/gdk/gdk-Event-Structures.html#GdkEventButton

<http://www.gtk.org/api/2.6/gdk/gdk-Event-Structures.html#GdkEventButto
n>).  
You can compare the GdkWindow pointer to the GdkWindow corresponding to

your Gtk::TreeView in your connected callback slot to determine whether

or not to allow the cursor to change depending on the validation of
your 
controls in your notebook page.

Connection code looks like this:

Gtk::Main::signal_key_snooper().connect(sigc::mem_fun(*this,&<your
class 
name here>::<your callback slot name here>));

I don't know if this will actually work, but I do know that you can 
choose to go ahead a propagate the event or not in your callback.  If 
you do propagate it, you must be sure to prevent catching that event a 
second (and third and fourth and so forth) time.

Hope this might help.

Bob Caryl