Re: Cross-coupling comboboxes
> AFAICT the "blocking" has to be > applied per-signal, so I need to keep track of all the connection > instances for all the comboboxes, yes? Yeah, I often forget that glibmm/gtkmm use Glib::SignalProxy rather than sigc::signal. The former will need you to retain and un/block the individual handler connections, whereas the latter would've let you do all at once. I guess it makes sense; we don't normally want to have to block everything including GTK/GLib's own handlers. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
On 08/06/2019 12:44, Daniel Boles via gtkmm-list wrote: > There may be a better fix. It would be nice if calling clear() on the > model didn't invoke the signal_changed of BOTH comboboxes 328 times each Blocking the signal is another way to do it. That may or may not have any quantitative difference in speed (from sigc not having to call your handler), but it might well lead to nicer handler code if you don't have to check for all the abnormal conditions, by simply blocking so it's never called in such cases instead. Yes, that sounds like a possibility. AFAICT the "blocking" has to be applied per-signal, so I need to keep track of all the connection instances for all the comboboxes, yes? Another idea I have is to unset the model from the ComboBoxes before clearing the model, then reassociate it with them afterwards. That might result in only notify::model being emitted, rather than all the ::changed. That also sounds promising. I had wondered about something similar (making the new model separately, then swapping to it, before deleting the old one) but if there's no issue with the comboboxes being "disconnected" for the duration of the update then your version would be easier. Thanks. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
> There may be a better fix. It would be nice if calling clear() on the > model didn't invoke the signal_changed of BOTH comboboxes 328 times each Blocking the signal is another way to do it. That may or may not have any quantitative difference in speed (from sigc not having to call your handler), but it might well lead to nicer handler code if you don't have to check for all the abnormal conditions, by simply blocking so it's never called in such cases instead. Another idea I have is to unset the model from the ComboBoxes before clearing the model, then reassociate it with them afterwards. That might result in only notify::model being emitted, rather than all the ::changed. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
On 07/06/2019 21:11, Rob Pearce wrote: And when it does so, the iterator returned by get_active() is invalid, which my code doesn't test for in the secondary case, so that would be worth doing... hold on... Yep, that seems to have fixed it. There may be a better fix. It would be nice if calling clear() on the model didn't invoke the signal_changed of BOTH comboboxes 328 times each (I think I mentioned the selection is getting rather large) but as long as I return immediately if get_active() returns an invalid iterator then it doesn't cause problems. Thanks for your help. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
> What appears to happen, which I wasn't expecting, is the m_refTreeModel->clear(); call invokes the combobox signal_changed handler for every row? yeah, gtk_combo_box_model_row_deleted() does that if the reference to the previous active_row is now invalid, and i presume sets the active model to the nearest still-valid one, and so on, etc. another way around this might be to block the signal while you clear the model. ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
On 07/06/2019 19:56, Daniel Boles via gtkmm-list wrote: It's not particularly clear what's going on. Posting the minimal code required to reproduce this on a pastebin and linking it would be great. Yes, I know, but this is all well embedded into a large code base, so it won't be easy. I'll try building up from my initial hack of the ComboBox example to see if, and with which additions, I can reproduce the problem. Are you taking an iterator into the model, then clearing the model, then trying to use the former iterator again? That definitely won't end well, I don't think. No. At least, not knowingly. The only place I'm using an iterator is for the "signal_changed" handler of one combobox to pass it directly to the other combobox. (well, there are other places where I use one to iterate or to populate a newly added entry, but those aren't involved in this bit). What appears to happen, which I wasn't expecting, is the m_refTreeModel->clear(); call invokes the combobox signal_changed handler for every row? And when it does so, the iterator returned by get_active() is invalid, which my code doesn't test for in the secondary case, so that would be worth doing... hold on... ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
It's not particularly clear what's going on. Posting the minimal code required to reproduce this on a pastebin and linking it would be great. Are you taking an iterator into the model, then clearing the model, then trying to use the former iterator again? That definitely won't end well, I don't think. In that case you probably should indeed use either TreePath or :active-id, since those are only instructions how to get to the right place in an equivalent model - rather than being intrinsically tied to the validity of the original state of the same model, like iterators are. That said, even path/ID probably only work if, after you clear and rebuild for whatever unclear reason, the item you want to reselect has the same path/ID (or you're happy to select a different item that now has that path/ID). ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
On 07/06/2019 13:26, Daniel Boles via gtkmm-list wrote: >>> /Now, using the TreeModel and passing iterators, I get a shed load of Gtk-CRITICAL **: 12:24:08.859: gtk_tree_store_get_path: assertion 'iter->user_data != NULL' failed interspersed with my own debug report of invalid iters passed to on_combo_changed() I don't think this is connected with the coupling. If I comment out the forward coupling call it makes little difference. I've also tried calling unset_active() before the clear() but it didn't help./ >>> Yep: ``` G_DEBUG=fatal-criticals gdb ./your_exe run bt ``` That gives me: Thread 1 "vpctrl" received signal SIGTRAP, Trace/breakpoint trap. 0x75c87745 in _g_log_abort () from /usr/lib64/libglib-2.0.so.0 (gdb) bt #0 0x75c87745 in _g_log_abort () from /usr/lib64/libglib-2.0.so.0 #1 0x75c88a51 in g_logv () from /usr/lib64/libglib-2.0.so.0 #2 0x75c88c2f in g_log () from /usr/lib64/libglib-2.0.so.0 #3 0x7732ac04 in gtk_tree_store_get_path () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x77a8cfb6 in Gtk::TreeModel_Class::get_path_vfunc_callback(_GtkTreeModel*, _GtkTreeIter*) () from /usr/lib64/libgtkmm-2.4.so.1 #5 0x771bf7fa in gtk_combo_box_set_active_iter () from /usr/lib64/libgtk-x11-2.0.so.0 #6 0x5562c6e2 in TRateControlDlg::SetMaterialComboIter (this=0x559fcf30, iter=...) at AutoControl.h:60 #7 0x5562c231 in TAppWindow::SetMaterialIter (this=0x7fffd880, iter=...) at MainView.cc:993 #8 0x55678041 in MaterialSelector::on_combo_changed (this=0x5597b628) at DepositionView.cc:570 #9 0x5567f8f2 in sigc::bound_mem_functor0MaterialSelector>::operator() ( this=0x559f4478) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991 #10 0x5567f4ee in sigc::adaptor_functor >::operator() (this=0x559f4470) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256 #11 0x5567ef40 in sigc::internal::slot_call0MaterialSelector>, void>::call_it (rep=0x559f4440) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136 #12 0x766b61a8 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib64/libglibmm-2.4.so.1 #13 0x75d63b6d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #14 0x75d763e3 in signal_emit_unlocked_R () from /usr/lib64/libgobject-2.0.so.0 #15 0x75d7f802 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #16 0x75d7fe6f in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #17 0x771b9c81 in gtk_combo_box_set_active_internal () from /usr/lib64/libgtk-x11-2.0.so.0 #18 0x55678a4c in MaterialSelector::Populate (this=0x5597b628) at DepositionView.cc:676 #19 0x5567b938 in TDepositionView::Populate (this=0x5597b470) at DepositionView.cc:883 and thence into bits of my code. With the coupling commented out, the backtrace is: Thread 1 "vpctrl" received signal SIGTRAP, Trace/breakpoint trap. 0x75c87745 in _g_log_abort () from /usr/lib64/libglib-2.0.so.0 (gdb) bt #0 0x75c87745 in _g_log_abort () from /usr/lib64/libglib-2.0.so.0 #1 0x75c88a51 in g_logv () from /usr/lib64/libglib-2.0.so.0 #2 0x75c88c2f in g_log () from /usr/lib64/libglib-2.0.so.0 #3 0x7732ac04 in gtk_tree_store_get_path () from /usr/lib64/libgtk-x11-2.0.so.0 #4 0x77a8cfb6 in Gtk::TreeModel_Class::get_path_vfunc_callback(_GtkTreeModel*, _GtkTreeIter*) () from /usr/lib64/libgtkmm-2.4.so.1 #5 0x771bf7fa in gtk_combo_box_set_active_iter () from /usr/lib64/libgtk-x11-2.0.so.0 #6 0x556419e5 in MaterialSelector::set_active (this=0x55950a28, iter=...) at DepositionView.h:48 #7 0x55641a38 in TDepositionView::SetMaterialComboIter (this=0x55950870, idx=...) at DepositionView.h:128 #8 0x5563b221 in TRateControlDlg::MaterialClick (this=0x5581ae00) at AutoControl.cc:231 #9 0x556432f0 in sigc::bound_mem_functor0TRateControlDlg>::operator() ( this=0x55b059a8) at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1991 #10 0x55642df6 in sigc::adaptor_functor >::operator() (this=0x55b059a0) at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:256 #11 0x556427d8 in sigc::internal::slot_call0TRateControlDlg>, void>::call_it (rep=0x55b05970) at /usr/include/sigc++-2.0/sigc++/functors/slot.h:136 #12 0x766b61a8 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib64/libglibmm-2.4.so.1 #13 0x75d63b6d in g_closure_invoke () from /usr/lib64/libgobject-2.0.so.0 #14 0x75d763e3 in signal_emit_unlocked_R () from /usr/lib64/libgobject-2.0.so.0 #15 0x75d7f802 in g_signal_emit_valist () from /usr/lib64/libgobject-2.0.so.0 #16 0x75d7fe6f in g_signal_emit () from /usr/lib64/libgobject-2.0.so.0 #17 0x771bcf76 in
Re: Cross-coupling comboboxes
>>> *Now, using the TreeModel and passing iterators, I get a shed load of Gtk-CRITICAL **: 12:24:08.859: gtk_tree_store_get_path: assertion 'iter->user_data != NULL' failed interspersed with my own debug report of invalid iters passed to on_combo_changed() I don't think this is connected with the coupling. If I comment out the forward coupling call it makes little difference. I've also tried calling unset_active() before the clear() but it didn't help.* >>> Yep: ``` G_DEBUG=fatal-criticals gdb ./your_exe run bt ``` ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
Thanks, it seems to work. At least, mostly... One of the other changes I'm making needs me to test an existing bit of functionality which replaces the underlying "stuff". This means that the TreeModel content is clear'd then re-built. With the simple list and ComboBoxText, this worked fine. Now, using the TreeModel and passing iterators, I get a shed load of Gtk-CRITICAL **: 12:24:08.859: gtk_tree_store_get_path: assertion 'iter->user_data != NULL' failed interspersed with my own debug report of invalid iters passed to on_combo_changed() I don't think this is connected with the coupling. If I comment out the forward coupling call it makes little difference. I've also tried calling unset_active() before the clear() but it didn't help. Any ideas? On 07/06/2019 09:15, Carlos Gomez wrote: In that case I think so, but never did. Give it a try. My idea was to use Path to get an iterator, but if we are talking about the same instance, the iterator should work. On 06/06/2019 18:13, Rob Pearce wrote: On 06/06/2019 09:18, Carlos Gomez wrote: If both ComboBoxes has the same items, perhaps you should use Gtk::TreeModel::Path. They not only have the same items, they share a TreeModel instance and a TreeModel::Columns instance (I believe this is an officially approved scheme). So yes, Path should work. In fact, can I not use the ::iterator directly? ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
In that case I think so, but never did. Give it a try. My idea was to use Path to get an iterator, but if we are talking about the same instance, the iterator should work. On 06/06/2019 18:13, Rob Pearce wrote: On 06/06/2019 09:18, Carlos Gomez wrote: If both ComboBoxes has the same items, perhaps you should use Gtk::TreeModel::Path. They not only have the same items, they share a TreeModel instance and a TreeModel::Columns instance (I believe this is an officially approved scheme). So yes, Path should work. In fact, can I not use the ::iterator directly? ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
On 06/06/2019 09:18, Carlos Gomez wrote: If both ComboBoxes has the same items, perhaps you should use Gtk::TreeModel::Path. They not only have the same items, they share a TreeModel instance and a TreeModel::Columns instance (I believe this is an officially approved scheme). So yes, Path should work. In fact, can I not use the ::iterator directly? ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
Hi, If both ComboBoxes has the same items, perhaps you should use Gtk::TreeModel::Path. On 05/06/2019 18:58, Rob Pearce wrote: Hello experts, I have a GTKmm (2.24) application in which two different windows each have a ComboBoxText controlling the same item, so that whenever the user makes a selection on one of them, the other one needs to be updated accordingly. This is implemented by calling the set_active with the result of get_active_row_number. Because the content of those combo boxes has got rather voluminous, I now want to convert them to hierarchical. So the ...Text version is no good and I'm using a ComboBox with a TreeStore behind it. The row number obviously no longer works, so... What's the best way to do this? Thanks, Rob ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Re: Cross-coupling comboboxes
>>> This is implemented by calling the set_active with the result of get_active_row_number. Because the content of those combo boxes has got rather voluminous, I now want to convert them to hierarchical. So the ...Text version is no good and I'm using a ComboBox with a TreeStore behind it. The row number obviously no longer works, so... >>> I don't know if GTK+ 2 had these, but as of GTK 3, I would look into property :active or :active-id (ensuring rows have values for those of course). You could continue syncing them manually, if you need or simply want to, or alternatively you could automate it via GLib's bind_property(). ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
Cross-coupling comboboxes
Hello experts, I have a GTKmm (2.24) application in which two different windows each have a ComboBoxText controlling the same item, so that whenever the user makes a selection on one of them, the other one needs to be updated accordingly. This is implemented by calling the set_active with the result of get_active_row_number. Because the content of those combo boxes has got rather voluminous, I now want to convert them to hierarchical. So the ...Text version is no good and I'm using a ComboBox with a TreeStore behind it. The row number obviously no longer works, so... What's the best way to do this? Thanks, Rob ___ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
