Re: [ruby-gnome2-devel-en] Bug in Gtk::TreeView#set_cursor ?

[<dp...@gm...>]

i have edited your script to the point where i found out what is 
happening, but i lost it :(.
basically i disabled the treeview's focusing ability, thus it did not do 
the tab trick(but did not focus on cells).
i changed your TreeView.grab_focus to 
nextCellRenderer_to_edit.grab_focus (this solved the problem of 
grab_focus forces the CellRenderer to exit editing mode)
and i hooked the editing-canceled and editing-started signals to see 
what is happening, and i found out that when that strange behavior 
occurs  it's because of a premature editing-canceled event is called on 
the second CellRenderer.

and i concluded that if you want to imitate an excel-like grid object 
than you'll end up writing your own CellRenderer object, better your own 
TreeView, which will not be a TreeView, but probably a Gtk::Layout or a 
Table with Labels/Entries(in editing mode) on it.
for one reason, TreeView has a row selection mechanism, and it'll not 
emit the editing signal to the CellRenderer if the row is not selected 
first, which means at least two mouse clicks to enter a Renderer's 
editing mode which was not in the selected row.

Joachim Glauche wrote:
> Dobai-Pataky Bálint wrote:
>   
>> hmm, yeah.
>> but at least we know now: treeview.grab stops the editing, which was
>> started by set_cursor
>>     
>
> The question is why. The manual says
> "This method is often followed by Gtk::Widget#grab_focus in order to 
> give keyboard focus to the widget."
>
> So, what, instead of the treeview, should I focus to get the next cell 
> focused (must be not stop editing)?
>