I have some places in my QML code where an Item created by Repeater needs
to interact with the other Items managed by the Repeater. So it does
something like:
onXXXChanged: {
for(var i = 0; i < repeater.count; i++) {
var item = repeater.itemAt(i)
...
}
}
in reaction to various events.
However itemAt() -quite unpredictably, meaning sometimes it doesn't
happen- can return null (usually on the last item). Sure the docs say
that itemAt could return null if items does not exist, and that count
can be higher than the actual number of items during the process of
instantiating items, so it is kind of to be expected.
The solution seems to be to check for null before proceeding. It would
also be possible to bind to itemAdded/itemRemoved signals of Repeater,
but not practical in my case.
However, wouldn't it be more useful to change count only when the last
item is actually available? (binding to count allows for more
declarative code; binding to signals allows reactive code, which I
find somewhat inferior to declarative code; when reading this
consideration please disregard my code snippet above, which is not
particularly declarative ^.^...)
Is there a "declarative" reason for behaving the way it behaves now?
Cheers,
Federico Ferri
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
