I’m getting an empty list for “all Label in clone”, although “clone” itself is populated. The label in the clone is unchanged.
This is definitely related to the ‘clone’ block, because if I switch out ‘row_to_clone’ for ‘clone’, everything works as expected.
Here’s a link to the minimalist project: Thunkable
I was really hoping /not/ to do what’s in this post, because it looks like a pain in the rear, and potentially fragile if I make UI changes later.
I feel like that should work. And yet it doesn’t. The green clone block holds an object (a row, copied from the original). So you should be able to get the first list item from the list of “all Label in clone”. Yet it doesn’t change the cloned label’s text so I’m a bit baffled.
A clue is that it’s not displaying the clone block’s object data as JSON. I just see when it’s previewed. Or rather, it is displaying it but it’s empty.
So… If I add a wait block as the first block within the clone’s ‘do’, it works. Exactly as expected. Apparently ‘clone’ needs some time to get populated?
Somebody who looks a lot like me figured out a while ago that a wait block was needed when cloning components as part of a loop but… you weren’t using a loop so that’s surprising.
Interesting that you found that a wait block after the cloning loop was necessary. So it’s almost as if the clone block starts the process but the “all buttons” list isn’t populated with the new objects until all of the cloning is completed.
My assumption would be that the “do” section of the clone block would have a delay built in. But that doesn’t seem to be the case.
@domhnallohanlon Any clarification on this? Curious if the clone block just needs a little reworking.
I wasn’t actually cloning in a loop, but in response to a button click. As a single event, it still needs that wait.
I really like Thunkable, but it annoys me that an early step in my debugging process has become sprinkling wait blocks everywhere to see if the problem vanishes. I want a “no, seriously, don’t go on until the previous step is done” block.
I realize yours wasn’t a loop which is what surprised me about needing the wait block. I’ve seen this happen where someone has a clone block or database lookup block inside a fast loop and the requests they are sending don’t have enough time to complete.
But the fact yours wasn’t in a loop was what seemed strange. I wouldn’t expect it to need a delay but based on what @muneer shared, I see that it does need a wait block.
I think what’s different about my case is that I need a wait to use the contents of the clone WITHIN the do block of the clone itself. I thought those asynchronous purple blocks at least didn’t start on their ‘do’ until they were done…
The clone value is populated right away, but the contents of the clone need time to be there…
There was a problem like this a while ago. I can’t remember if it was with the clone block specifically but it may have been. The “do” section was simply running immediately. It was fixed so hopefully this isn’t a difficult fix.