Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
[solved]QTreeView : Child-indicator is not updated after inserting children
This is my second post in a few minutes :)
...and the problem is similar the the one from my first post: http://qt-project.org/forums/viewthread/18504/
I guess that the solution could be the same, but the situation is different:
I am developing a TreeView (for a Usermanagement, groups are nodes, users are childs) in which it is possible
to dynamically add TreeItems to other TreeItems (as children).
I call beginInsertRows before and endInsertRows after creating the new Items. In standard-cases eveything seems to work fine, as long as the parentitem I am adding children to already has children. If the new inserted items are the first ones, they are also correctly inserted into my underlying data-structure, but the parentitemin the treeview does not update its branch/child-indicator.
So it looks like there was nothing added. I have to rebuild my whole tree (via reset()) to make the changes visible...
(I guess it will be the same when I remove the last items and the childindicator should diappear, but my implementation isn't finished, so I have no possibility to test this second case)
Can someone tell me how I can advise the TreeView to update correctly without updating everything (by calling reset())??
Jeroentjehome last edited by
I would think you need to emit the datachanged signal of the parent and not only of the child you inserted.
This is from the mind....can check the books if needed.
I've already tried this one (and tried it again after I read your answer ;) , but unfortunately this doesn't help.
As far as I know, dataChanged affects only the data of a treeitem (e.g. the displayed text, icons...), that means, everything that is queried through QAbstractItemModel::data()... but the branch-indicator is not part of the itemdata, but of the treestructure, and so dataChanged() has no effect on it...
The only idea I have left, is removing and re-inserting the parentnode... but I'm sure there must be a better (and more performant) way to update the indicator.
Ok, I found a solution, but I think this is some kind of bug...
I inserted the child as follows:
@beginInsertRows(index, pItem->childrenCount(), pItem->childrenCount()); //index is the index of pItem, which is the parent I'm inserting to
new CTreeItem(pData, pItem);
This should insert the new Item after the last child of pItem, and it does so when there are already children, if childrenCount() is 0 nothing happens. This is a bug in my opinion, because according to the documentation of QAbstractItemModel::beginInsertRows() the first item has index 0 and the parameter first specifies the new child-index my item will have (which should be 0 when it is the first item)
Please correct me if I'm wrong... (Or tell me that I'm right ;)
Anyway, I fortunately use a QSortFilterProxyModel, so I do not have to care about the child-order in my model... now I'm just calling beginInsertRows(index, 1, 1) no matter if index already has children or not, and it works...
If you use
beginInsertRows(index, pItem->childrenCount(), pItem->childrenCount());
then, with a parent item pItem without children, this literally translates to
beginInsertRows(index, 0, 0);
so, actually you're telling your model that you are going to insert zero items. I would call no update on the parent item as the correct reaction of the model to that :-)
But then the documentation on that is a bit confusing... because it says the two ints are the positions of the new items...
@The parent index corresponds to the parent into which the new rows are inserted; first and last are the row numbers that the new rows will have after they have been inserted.@
...and if there aren't already items, the new one has of course position 0.
Which for my understanding means that beginInsertRows(index, 0, 0); should insert the new item at position 0, and because the last position is also 0, there's only one inserted.
If this is interpreted as a count, it's a "bug" in the doc ;)
When I call beginInsertRows(index, 1, 1); it does work, but I get the debug message "QSortFilterProxyModel: invalid inserted rows reported by source model", so there has to be a better solution...
Oh, you're right, of course. I didn't read the docs and stand corrected here.
It looks a bit weird, though. I don't have problems with that in my own models, it works as expected.
Do methods hasChildren() and rowCount() on the parent index return the correct values afterwards?
Maybe it can help to set the parent expanded, using slot expand().
I already tried expanding the parent, without any effect.
When I query hasChildren() and rowCount() on the index used as parent in beginInsertRows immediately after endInsertRows rowCount() returns 1, and hasChildren() returns true...
it still returns 1 and true when i call the non-updating version beginInsertRows(index, pItem->childrenCount(), pItem->childrenCount())... (and no debug message in this case)
Can you create a small, self contained test case? It's hard to help further without the "working" failure.
[quote author="Volker" date="1343338405"]Can you create a small, self contained test case? It's hard to help further without the "working" failure.[/quote]
Lol... I already tried to create a small test-project containing the error for posting it here, but I didn't get the error again :D
I'll give it another try this weekend...
But in the meantime we found out that the error is somehow related to the SortFilterProxyModel I use:
if I do not use this ProxyModel, everything works fine (without sorting and filtering of course)
In this ProxyModel I overwrite lessThan() and filterAcceptsRow(), and call setDynamicSortFilter(true) in the constructor... thats all it does.
That's the code of my ProxyModel (shortened):
c_pDataSource = NULL;
//Needed for comparisons in lessThan and filterAcceptsRow
void MySortModel::setUserData(MyDataManagingClass *pDataSource)
c_pDataSource = pDataSource;
bool MySortModel::lessThan(const QModelIndex &left, const QModelIndex &right) const
pLeftItem = static_cast<MyTreeItem*>(left.internalPointer());
pRightItem = static_cast<MyTreeItem*>(right.internalPointer());
if (!pLeftItem || !pRightItem)
//Do some comparisons and return true or false...
bool MySortModel::filterAcceptsRow(int source_row, const QModelIndex &source_parent) const
iColumn = filterKeyColumn();
qrFilter = filterRegExp();
if (qrFilter.isEmpty() || !qrFilter.isValid())
//No filter, show all
//Get Item to filter
//pItem is Top-Level
pItem = static_cast<MyTreeItem*>((static_cast<MyModel*>(sourceModel()))->getBufferRoot()->getChild(source_row));
//pItem is Child
pItem = (static_cast<MyTreeItem*>(source_parent.child(source_row, 0).internalPointer()));
//Do some comparisons to determine if pItem is displayed and return true or false...
in the class creating the QTreeView I do the following (again shortened):
c_pSortModel = new MySortModel(this);
c_pModel = new MyModel(pDataSource); //c_pModel: Inherited from QAbstractItemModel
c_pTreeView = new QTreeView(this); //Do some initializing on c_pTreeView and add it to this widgets layout c_pTreeView->setSortingEnabled(true); c_pTreeView->setModel(c_pSortModel); //call c_pTreeView->setModel(c_pModel) to avoid Bug
and that's how the new Item is inserted:
//In a slot connected to a changed-signal emitted by my DataSource-class:
if (pItem) //previously determined; everything works fine to this point
beginInsertRows(index, pItem->childrenCount(), pItem->childrenCount()); //in the error-case childrenCount() returns 0 (correct, new Item is first child), so the new Item should become item 0 (the first), so everything should be fine...
new MyTreeItem(pData, pItem); //pItem is set as parent, the tree-structure is set up correctly
//calling reset() afterwards would help, but I don't want to do that for performance reasons
So I hope I suceed in building a demo-project containing exact the same error, but as I already tried, I can't promise...
But perhaps the code I posted already helps...
I wasn't able to reproduce the error in a small demo-project...
but I found another workaround:
emit layoutAboutToBeChanged() before and emit layoutChanged() after inserting the row helps.
And seems to be better than inserting as Item 1, 1 as that caused an assertion in qsortfilterproxymodel.cpp in some cases. The layoutChanged-version does not (and doesn't give me the invalid rows debug message)...
If somebody is still interested in this:
The problem was the columnCount given by my model: QAbstractItemModel::columnCount() didn't return the same value for every index, and QTreeView doesn't seem to like that ;)
Now it always returns the same number and everything works fine.
Christon last edited by
Following line saved my second day on same issue!
"The problem was the columnCount given by my model"