@JonB
This code is a small example to find solution.
In my real project i need to show tree with different items and nested trees.

treeWidget->model()->removeRows(0,treeWidget->model()->rowCount()); clears the widget of all items and deletes them freeing the memory (see the sources if you don't believe me). Be aware that it's difficult to assess memory usage live in debug mode as the OS might keep the memory allocated for a while after you call delete

It seems you can't with the current API. There's a private bool QTreeWidgetItemIterator::matchesFlags(const QTreeWidgetItem *item) const method of the iterator that does the checking of flags, but the user defined ones are not checked in any way.
It would make sense to make that function virtual protected, so you could inherit and extend the iterator to match your needs, but it's not in there (yet?). You could probably make a suggestion for that on the bugreports.qt.io.

After disabling a whole bunch of Windows policies suddenly I get the desired behaviour.... that is surprising. I still don't know the root cause, but I'll postpone looking further until the problem reappears

@Jakob
Ah, yes. From Qt4 you get:
# define Q_SIGNALS protected
I firmly believe that this change was made to accommodate the new way of connecting signals. I don't find it to be a great improvement, but this is a personal opinion ... In the new framework it seems every object can easily rise another object's signal, which is a bit ... hm ... suspicious ... not that it was impossible before, but you had to go the extra mile, by using the QMetaObject class.

As it turned out, one must explicitly say QTreeView::indicator:unchecked in order to set the general settings like background color for this checkbox. That was a bit surprising, as this is not needed for instance for QCheckbox::indicator or QGroupBox::indicator, but the solution is now here for posterity

As a first go I tried the suggestion by @SGaist, which turned out to do exactly what I need for now. We're writing a lot from scratch, so for the future I'll certainly keep the idea of @kshegunov in mind, since it sounds a bit more flexible, so it may be required to support more advanced use cases coming our way in the (near) future.

Thanx to both!

What is the stack trace when this happens ?

@Bart
Hi,
please
put

QHash<QString, QTreeWidgetItem * > Parents;

outside the for loop.
Also,
you say

if(blades.contains(ArraySet1[i][0]))

Should that not be Parents?
Anyway, when Contains is true, you do not create a new QTreeWidgetItem but instead use the one you store in the
hash list. that way you will connect to the same Parent (the first one) when you see the same name again.
We use the list to keep track of ParentName, and the QTreeWidgetItem that we created with that name.
so

if(blades.contains(ArraySet1[i][0])) { QTreeWidgetItem *y = new QTreeWidgetItem(); y>setText(0,ArraySet1[i][1]); x->addChild(y); <----------------- x here should be the parent you stored in the hash list }

becomes

if(Parents.contains(ArraySet1[i][0])) { QTreeWidgetItem *NewChild = new QTreeWidgetItem(); NewChild>setText(0,ArraySet1[i][1]); QTreeWidgetItem *StoredParent =Parents.value(ArraySet1[i][0]); StoredParent ->addChild(NewChild) } else { // create the new parent and store in list QTreeWidgetItem *x = new QTreeWidgetItem(ui->treeWidget); x->setText(0,ArraySet1[i][0]); ui->treeWidget->addTopLevelItem(x); Parents->Insert( ArraySet1[i][0], x ); // store our parent under that name QTreeWidgetItem *y = new QTreeWidgetItem(); y->setText(0,ArraySet1[i][1]); x->addChild(y); QTreeWidgetItem *z = new QTreeWidgetItem(); z->setText(0,ArraySet1[i][2]); y->addChild(z); l }

something like that. Hope it makes sense.
ps. did not try to compile so might be syntax errors.

@SGaist Oh, OK... Then I'll implement that too and see how it goes. Thanks.