The site that you link to suggests using gtk_tree_model_iter_n_children().
The corresponding function in gtkmm is Gtk::TreeNodeChildren::size().
You should be able to use imgTPTreeViewPointer->children().size().
Don’t use Gtk::TreeModel::iter_n_children_vfunc() unless you make your own
implementation of the TreeModel interface.
If you just want to remove all rows in your TreeStore, must you really know
if it’s empty or not? Can’t you call Gtk::TreeStore::clear() unconditionally?
If the TreeStore is empty, clear() should do nothing.
if (imgTPTreeViewPointer->children().size()>0)
{
auto children = imgTPTreeViewPointer->children();
for (auto iter = children.end(),begin = children.begin();iter != begin;--iter)
{
auto row = *iter;
imgTPTreeViewPointer->erase(iter);
}
}
I have raised a separate issue for TreeView not getting erasing the previous rows after I do TreeStore->clear() here TreeStore clear not erasing the previous data. Please do help in case you know how to correct it
As in typical C++ containers, children.end() points one step behind the last element
in the container. TreeNodeChildren has no rbegin() and rend() iterators, which makes
it difficult to iterate in reverse.
When the Clear button is pressed, the result is as expected
Before clear(): 3
After clear(): 0
and the 3 rows are deleted from the GUI.
Have I understood you correctly? When you call m_refTreeModel->clear(), nothing happens.
The ListStore still contains 3 rows and those 3 rows are shown in the GUI.
The GUI rows remains, when I add new rows it gets appended to the previous row.
If previous data had 3 rows after I clear children shows as 0, then I add additional 3 rows. The new data gets appended are new rows. Top three rows contain latest data, while the last three contain the old data.
imgTPTreeColumn still has the previous values those are being shown I guess. Don’t know how to clear it as the class has only add no clear or remove according to this Gtk::TreeModelColumnRecord Member List
I can’t explain why your GUI is not updated correctly. I found, though, that issues
have been reported concerning a pixel cache in GtkTreeView. See for instance gtk#503.
Different versions of gtk may behave differently. I’ve tested with gtk 3.24.36.
Which version of gtk have you got? Note that it’s the gtk (a.k.a gtk+) version
that matters, not the gtkmm version.