Hi,
On Thu, 30 Jun 2022 at 12:43, Federico Ferri
wrote:
>
> My real-use case is too complex, but consider the simple scenario of a UI
> control that features an array of whatever controls, say checkboxes, and
> computes an aggregate property, i.e. a function of all the checkboxes states
>
My real-use case is too complex, but consider the simple scenario of a UI
control that features an array of whatever controls, say checkboxes, and
computes an aggregate property, i.e. a function of all the checkboxes
states f(repeater.itemAt(0).checked, repeater.itemAt(1).checked, ...).
So I
Hi,
Although I haven't looked deep inside the Repeater implementation to
answer _why_ you see the behavior described, I think you already
answered the question of why you are facing difficulty. It is not very
declarative to expect these things to happen in a certain order.
Especially when it
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)
...
