> 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
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
> 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
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
> 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
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
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
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
>>>
*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
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.
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,
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
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
>>>
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
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
15 matches
Mail list logo
