ListView indexAt stopped working on switching from ListModel to C++ model

[Bob64]

I have a ListView that has been using a ListModel as its model but I am attempting to replace it with a C++ model derived from QAbstractListModel. The ListModel 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 using ListView.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 the ListModel 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 the ListView should not even care which model is being used. Given that, how can indexAt fail for one model but work for the other?

[Bob64]

@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 my ListView 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 stop indexAt from working. I have since exposed the missing property and indexAt now returns the expected indices rather than -1 all the time.

[fcarney]

@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.

[GrecKo]

As always, post a minimum reproducible example if you want help.
A ListModel is a QAbstractListModel, ListView shouldn't handle it differently.

[Bob64]

@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 my ListView 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 stop indexAt from working. I have since exposed the missing property and indexAt now returns the expected indices rather than -1 all the time.