Re: using TreeView::set_cursor in a function connected to CellRendererText::signal_edited

["Andrew E. Makeev" <andrew solvo ru>]

I just would to say that I am using "auto"-start editing cells in my app
with gtk2+ v2.10/v2.12. And my callbacks are connected at
CellRenderer::signal_edited() and Widget::signal_focus_out_event() for
cell widget. The difference is that I am not calling
TreeView::set_cursor from signal handler directly.

I am using Glib::Dispatcher (that usually lets gtk main thread handle
events from other threads) to submit my callbacks in pool. So, main loop
could do some iterations and handle destroying cell widget. After that
it is safe to start editing again. Of course there is chance that widget
destroying was not done, and my app fails sometimes.

I guess you just have to find right place where to connect your signal
handler. For example, Container::signal_remove() for TreeView or
Widget::signal_unmap() for cell widget. Probably you would to override
CellRenderer::start_editing_vfunc() to get access to all right object.
I can't prove that it will work, honestly, didn't try it myself.

Regards,
-Andrew

В Чтв, 01/08/2013 в 20:55 +0200, Jonas Platte пишет:
> Okay I just wanted to make sure because my former bug reports got
> responses very quickly.
>
> And you're absolutely right about how much great work all contributors
> do. I hope to some day I'll contribute code too :)
>
> Am 01.08.2013 20:37, schrieb Kjell Ahlstedt:
>
> > Yes, it's normal that no one responds to a bug report within 10
> > days. The response time varies enormously. Some bugs get a response
> > within hours and a fix within a few days, others get no reaction for
> > years.
> > Kjell
> >
> > 2013-08-01 19:51, Jonas Platte skrev:
> >
> > > I filed a bug report a while ago and no one seems to respond to
> > > it. Is this normal? Should I increase the importance? The report
> > > is here: https://bugzilla.gnome.org/show_bug.cgi?id=704698
> > >
> > > Am 17.07.2013 15:32, schrieb Kjell Ahlstedt:
> > >
> > > > 2013-07-03 07:59, Kjell Ahlstedt skrev:
> > > >
> > > > > 2013-06-30 20:40, Jonas Platte skrev:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I'm having a little problem with editable cells: I have a
> > > > > > validity check for data entered into a editable cell, and if
> > > > > > it fails, I want to give the user another try to enter
> > > > > > something into that same cell.
> > > > > >
> > > > > > To get the focus to the previously edited cell again after
> > > > > > showing an error message, I use TreeView::set_cursor with
> > > > > > the last parameter start_editing set to true (while in the
> > > > > > signal handler for signal_edited of the cell renderer).
> > > > > >
> > > > > > The problem is that, when confirming the input by clicking
> > > > > > somewhere outside the cell, the UI gets messed up: the entry
> > > > > > for the edited cell is there as it should (and its content
> > > > > > is reset as it should), but can't be confirmed or aborted
> > > > > > anymore. I get the following error message on the command
> > > > > > line:
> > > > > >
> > > > > > Gtk-CRITICAL **: gtk_container_remove: assertion
> > > > > > 'gtk_widget_get_parent (widget) == GTK_WIDGET (container) ||
> > > > > > GTK_IS_ASSISTANT (container)' failed
> > > > > >
> > > > > > Is it just not allowed to use set_cursor while handling the
> > > > > > confirmation of editing a cell or is this a bug I should
> > > > > > file?
> > > > > I can confirm that the same thing happens with one of the
> > > > > example programs in the gtkmm tutorial,
> > > > > https://git.gnome.org/browse/gtkmm-documentation/tree/examples/book/treeview/editable_cells
> > > > >
> > > > > If the input in the cell is finish by pressing Enter, no
> > > > > critical message is printed. If the input in the cell is
> > > > > finish by moving to another cell, the critical message is
> > > > > printed.
> > > > > It looks like a bug, but I don't know if it's a gtkmm bug or a
> > > > > gtk+ bug.
> > > > >
> > > > > Kjell
> > > > I made some changes to the gtk+ test gtk+/tests/testtreeedit.c.
> > > > A pure gtk+ application shows the same bad behaviour as a gtkmm
> > > > application.
> > > > If you file a bug (or have already done so), make it a gtk+ bug.
> > > >
> > > > It may not be trivial to fix. If it can't be fixed, it should at
> > > > least be documented that gtk_tree_view_set_cursor() and
> > > > gtk_tree_view_set_cursor_on_cell() (and thus
> > > > Gtk::TreeView::set_cursor()) can't be used in a
> > > > GtkCellRendererText's edited signal handler.
> > > >
> > > > Kjell
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtkmm-list
-- 
Andrew E. Makeev <andrew solvo ru>
Solvo Logistic