Re: tree_view_set_cursor outlier case

[Paul Davis <paul linuxaudiosystems com>]

On Sun, Feb 12, 2012 at 11:37 PM, Enoch Langston <palmettojl yahoo com> wrote:

My name is Kevin and I work in IT support. I am new to the mailing list and development in general. I have found gtk both rewarding and difficult to learn. I have especially been having a rough time with figuring out how to deactivate a cell I have set to editing with a call to gtk_tree_view_set_cursor(). Once I've set the path via this function to enable editing I am worried about a user selecting another option in the treeview with a left click and notcing that the old path still has a text field in it and can be editited. Below is the function I wrote that gets called when someone selects rename on a popup menu which is one of the choices. I use this function to set the path to the cell to enable editing, I am also controlling editing in my tree model with a boolean property which I switch on just before calling this function. I need to know how to caputure the case that the user clicks on a different tree view path mid edit before actually submitting the editing cell with the "enter" key. Here is how I enable it, how do I disable it if they click somewhere else?

it is certainly tricky to discover and not well documented. luckily, its also simple once you know how.

the signal emitted when editing starts includes a pointer to a GtkCellEditable. you need to stash this away, and whenever you want to end editing programatically, you need to either call gtk_cell_editable_editing_done() or to cancel the edit, make it emit the "editing-done" signal with a TRUE argument (which indicates that editing was cancelled).

the mental leap that you have to make is that the editing is actually taking place in an entirely different widget than is used to display the cell, and so all operations related to editing involve that widget (which is a GtkCellEditable) and not anything already present in the treeview.

--p