ListView indexAt stopped working on switching from ListModel to C++ model
-
I have a
ListView
that has been using aListModel
as its model but I am attempting to replace it with a C++ model derived fromQAbstractListModel
. TheListModel
was generally working fine but it had a lot of JS associated with it and it had some performance issues. The C++ model displays fine but some selection functionality based on usingListView.indexAt
is failing.indexAt
is returning -1 for all input.Does this ring any bells for anyone? Are there some limitations with
indexAt
and C++ models? Otherwise, I can't understand it. Whether I use theListModel
or the C++ model, the view is correctly showing the model items at the correct positions. I am literally swapping out one model implementation for the other so theListView
should not even care which model is being used. Given that, how canindexAt
fail for one model but work for the other? -
@GrecKo Apologies, you are right - I should have created an example. The question followed some late night frustrations after spending a lot of time taking care to unit test what I thought would be the tricky parts of my C++ model, only to find that things were failing in a part of the code I assumed would work without issue.
In my defence, I was looking for general information on known issues rather than specific help - and indeed it was interesting to hear of @fcarney 's experiences.
Having said that, if I had tried to cut it down to a reproducible example I might then have found the issue that I have since spotted. I neglected to implement a property in my C++ model that existed in the
ListModel
. This was used to define the width of myListView
delegate. Surprisingly, I saw no errors in the debug console about accessing a non-existent property, and it also did not seem to prevent the delegate from rendering the model item correctly. However, it apparently was enough to stopindexAt
from working. I have since exposed the missing property andindexAt
now returns the expected indices rather than -1 all the time. -
@Bob64 said in ListView indexAt stopped working on switching from ListModel to C++ model:
QAbstractListModel
I have had problem with itemAtIndex always returning an undefined. This is similar to indexAt. So I stopped using those. The docs say it is for this reason:
"If there is no item at the point specified, or the item is not visible -1 is returned."
For the ListView I had problems with all the items were visible. So I don't understand why it was failing. It would also work in one setup and not in another. I could not track down why. -
As always, post a minimum reproducible example if you want help.
AListModel
is aQAbstractListModel
,ListView
shouldn't handle it differently. -
@GrecKo Apologies, you are right - I should have created an example. The question followed some late night frustrations after spending a lot of time taking care to unit test what I thought would be the tricky parts of my C++ model, only to find that things were failing in a part of the code I assumed would work without issue.
In my defence, I was looking for general information on known issues rather than specific help - and indeed it was interesting to hear of @fcarney 's experiences.
Having said that, if I had tried to cut it down to a reproducible example I might then have found the issue that I have since spotted. I neglected to implement a property in my C++ model that existed in the
ListModel
. This was used to define the width of myListView
delegate. Surprisingly, I saw no errors in the debug console about accessing a non-existent property, and it also did not seem to prevent the delegate from rendering the model item correctly. However, it apparently was enough to stopindexAt
from working. I have since exposed the missing property andindexAt
now returns the expected indices rather than -1 all the time.