2012-03-07 09:00, Murray Cumming skrev:
On Tue, 2012-03-06 at 22:28 +0100, Gerardo Ballabio wrote:
2012/3/6, Kjell Ahlstedt<[email protected]>:
I haven't tested this, but I think you shall call one of the
Gtk::TreeView::set_cursor() methods with start_editing = true.
That worked after I specialized on_expose_event() and put the call
there. Putting it in the constructor didn't work, even after
show_all_children(): the row was selected, but the cell wasn't open
for editing. I suppose between the constructor and the expose
something happens that turns off editing mode.
Maybe you were doing this in some other TreeView signal handler. I've
had similar problems, which I've solved by using a signal_idle handler.
connect_once() makes this fairly easy:
http://developer.gnome.org/glibmm/unstable/classGlib_1_1SignalTimeout.html#a4ea8fdd120102d7963709916f28b2bcc
I think it makes more sense to use this than an expose handler. I think
it's a common technique.
The description of Gtk::TreeView::set_cursor() says "Please note that
editing can only happen when the widget is realized." What about
connecting to TreeView's "realize" signal?
m_TreeView.signal_realize().connect(sigc::mem_fun(*this,
&ExampleWindow::treeview_on_realize));
void ExampleWindow::treeview_on_realize()
{
m_TreeView.set_cursor(Gtk::TreeModel::Path("1"),
*m_TreeView.get_column(1), true);
}
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
