The dataChanged Signal Not Performing as Expected

[Corny]

That does sounds a bit tricky, but what I'm attempting is not really all that complex. I'm going through the code right now and my thought at this point is that I may have gotten a bit confused with the QAbstractModel class documentation. The requirement for the dataChanged signal indicates two QModelIndex values need to be passed to the function, one for the top left corner of the data area and one for the top right. Since I'm only addressing one point (or cell), I was passing the same index value in both arguments. I'm in the process of verifying if that is a valid or invalid way of addressing just one point right now.

[d_stranz]

Actually, it's top left and bottom right, inclusive. From the docs:

If the items are of the same parent, the affected ones are those between topLeft and bottomRight inclusive.

This implies that if only one item is changed, the topLeft and bottomRight indexes should be the same. But for a tree view, this is important:

If the items do not have the same parent, the behavior is undefined.

This implies that if multiple items in the tree are changing at the same time, then you would need to emit multiple dataChanged() signals if the items come from different parts of the tree.

Top left and bottom right also implies that the items changing are contiguous between those two limits.

[Corny]

Actually, it's top left and bottom right, inclusive.

Thanks, you're absolutely correct, my bust. And as you have noted, I have managed to verify that using the same index value for both values references the one data point as desired.

As to your point concerning...

...would need to emit multiple dataChanged() signals if the items come from different parts of the tree.

not only is that key, but the fact that the data comes from multiple instantiations of an item, has me leaning towards your original assessment about using a mutex or some other form of thread blocking. As I'm only vaguely familiar with the subject, I've been attempting to study up on the subject, as well as more accurately define the timing of the model and its items.

Thanks again

Corny

[d_stranz]

Maya Posch has written a great book on C++ multithreading which includes examples using Qt, STL, and other threading implementations. I learned a lot from reading it and used it to solve more than one problem.

[Corny]

So, it turns out that earlier in the development process, I forgot that I had written some of the data points directly to the items without using the virtual function setData() in the sub-classed QAbstactItemModel. Of course the model is the only place that I was emitting the dataChanged() signal.

It looks like a simple logic error was the problem. Thanks again for all the help with this, I've learned a lot. Also, I'll check out that book by Maya Posch that you mentioned.

Corny

P.S. I would have marked this thread as solved but don't see a means of doing so.

[d_stranz]

I had written some of the data points directly to the items

Oops. Won't be the first time that's happened.

Maya Posch also has a great web site / blog with all sorts of interesting things, programming and beyond.

[Corny]

Though this thread is rather old, I’m posting this in the event someone else comes across the same situation. Even though I indicated that I thought I had found the problem. It wasn’t until a bit later that I figured out the real problem.

It turns out that the QAbstractItemModel documentation for dataChanged(), states among other things that...

[signal] void QAbstractItemModel::dataChanged(const QModelIndex &topLeft, const QModelIndex &bottomRight, const QVector<int> &roles = QVector<int> ())
...
The optional roles argument can be used to specify which data roles have actually been modified. An empty vector in the roles argument means that all roles should be considered modified. The order of elements in the roles argument does not have any relevance.

Based on other Qt documentation that shows a value assigned to an argument apparently indicating that it is an optional argument, and that I wanted to address all roles, I assumed (erroneously), that if you wanted to address all of the rolls the role argument could be an empty vector, or the role argument was optional. However, emitting the signal without a role argument appeared to work but proved to be problematic. Then, when I came across the QAbstractItemView documentation for the dataChanged() signal, it stated in part...

[virtual protected slot] void QAbstractItemView::dataChanged(const QModelIndex &topLeft, const QModelIndex &bottomRight, const QVector<int> &roles = QVector<int> ())
...
The roles which have been changed can either be an empty container (meaning everything has changed), or a non-empty container with the subset of roles which have changed.

Which I took to mean that the role argument itself is not optional and a container must be used as the argument, but the contents of the container can be empty if you want to address all roles.

Sending an empty container QVector<int> solved the problem.

[ChristianEhrlicher]

Which I took to mean that the role argument itself is not optional and a container must be used as the argument, but the contents of the container can be empty if you want to address all roles.

This is nonsense - not passing the third argument will let the compiler add the default value for the third argument which is an empty QVector<int>() - so it's *exactly to same if you call dataChanged(idx, idx2, QVector<int>()) or dataChanged(idx, idx2) or dataChanged(idx, idx2, {})

[Corny]

I'm not sure how to respond to your reply other than that when emitting the signal without anything for the roles argument dataChanged(idx, idx2), I encounter the problems outlined above. When I actually emit using dataChanged(idx, idx2, QVector<int>()), I no longer experience those problems. The results have proven to be repeatable on multiple test runs, using both methods of emitting the signal.

I may have stated it in a manner that is not easily understood, but as noted, I have run multiple tests using both methods, and have repeatably achieved the exact same results for the equivalent method used. Is there something that I'm not seeing?

[ChristianEhrlicher]

There must be another reason - from the C++ side it doesn't matter - see https://en.cppreference.com/w/cpp/la...ault_arguments or a good C++ book.

[Corny]

I don't disagree, that in C++ that's the way it works. However I am at a loss understanding what exactly is happening here. I am simply attempting to let anyone else who may run into a similar circumstance, know how I resolved the situation.

[d_stranz]

I don't disagree, that in C++ that's the way it works.

As Christian points out, there is absolutely no difference between emitting dataChanged() with two arguments vs. with a third argument being an empty (but explicitly declared) QVector<int>(). Both versions should compile to exactly the same thing (with the compiler inserting the default argument in the first instance), so there is absolutely no way that a slot receiving the signal can tell how it was called in the source code. If you are seeing a difference in behavior if you build and run code written first one way and then the other with no other code changes and exactly the same runtime test conditions then I would also be at a loss to explain why.