Threaded refreshing of a TreeView with custom model

[CLRS530]

I work on a big project using QTreeView with a custom model. I did a longer break because of other interests but more importantly because of a big (design) problem which I couldn't solve.
I often have to change the content of the tree view. I know layoutChanged has to be used there but it doesn't work in this case. I have to do a bigger process which uses a second thread and a progress window. While this will be done events of the model will be progressed on so many functions (index, parent...).
So the question is how this can be prevented. Please help I absolutely have no idea.

To explain it in more details. If through fetchMore happens a "special" case a longer progress starts in a second thread. In all other cases there is no problem. It took me some time to figure out that index and parent will be called from old or new events. I started with tries to ignore those calls but it could happen in too many functions and is a very bad method. All signals from Qt couldn't be used (modelReset) or used without effect.

There is no use of the tree view in the progress it's only to see how long it takes and for canceling so it could be disabled or something similar.

[CLRS530]

I somehow clicked on the wrong section. Could someone please move this thread to qt Programming?

[caduel]

I suggest you let your second thread aggregate the data in some struct and, once finished, update your model in one go using that struct. That way you avoid both the view accessing a partially updated model and have just one "update".

Also note that the model must only be updated from the gui thread.

[CLRS530]

I suggest you let your second thread aggregate the data in some struct and, once finished, update your model in one go using that struct. That way you avoid both the view accessing a partially updated model and have just one "update".

As you may think that's surely something I thought about earlier and it's a very complicated go. I will have a look again but I hoped for different solutions.

Also note that the model must only be updated from the gui thread.

I know the implementation works but most times it crashes because of the written reason.

[wysota]

You should use the concept of snapshots - snapshot (copy) the current data at the same time blocking user changes to the model (if applicable), rearrange the copied model data in the other thread and when you're done, attach the data back to the main root of the model.