I have an Alert inside a “for each item in list” loop.
It appears that the Alert is not Modal. ie: I need the App to wait for the User to press “confirm” or “cancel” first and then the App should act according to the “wasConfirmed” flag, and if true to continue in the loop, which may later throw up the same Alert again in the same loop.
However the loop just keeps looping and does not wait for the User to respond to the Alert dialog and press a button first.
Am I doing something wrong or is this a bug?
Is there a way I can force it to be Modal and for it to wait for User input?
If this is a bug, then it’s a show stopper and needs to be fixed asap.
Thanks
1 Like
You just may put an “repeat while” block right after the Alert, that will loop until some variable set by Alert’s response will permit to continue your initial loop.
Thanks!
I’ve tried a few things that don’t work.
Would you be able to provide some sample code?
If this workaround is required, then it implies that there is a bug in the Alert Logic.
If so: Thunkable please fix this asap.
As soon as I’ll get to my computer. (If no one else will provide in the time)
something like this:
1 Like
Hey there
So the issue is not a bug. It’s an issue of dealing with asynchronous code and forcing a for loop to wait for that asynchronous code to complete. You would likely be better off by creating a recursive function that calls itself after the user has provided an answer within the answer modal.
Essentially you need to be able to tell the for loop to wait until the user responds before it goes onto the next iteration or use a recursive function that calls itself after the user has responded.
Here’s an example of doing exactly that
Recursive Loop using Alert Example
1 Like
Hi Jared
Yes, I was considering the asynchronous part but surely a user dialog should stop the process?
The REST API call is completed and the data put into a list. At this point everything is completed and static.
I then iterate through the list and I’m wondering how on earth this can be an asynchronous task?
IMHO, it is a bug. The Alert block itself says: “Show” … and “Then Do if ‘wasConfirmed’”. How can it continue with the “then do”, if nothing was confirmed yet?
You need a “modal” option in the Alert Block. To do recursive calls or “repeats” is perhaps a workaround for a “shortcoming” but surely not best practise?
1 Like
I will say it may not be best UX but it is not a bug. I appreciate you following up here. Perhaps this topic requires further explanation.
The way the blocks are designed when using an asynchronous function requires you to nest the rest of the workflow within the then-do of the async block present in the workflow. This is common in many programming languages. It would be nice if the alert blocked everything under it from running until an option was chosen but it doesn’t att this time.
We do have async blocks that function like that but you’ll notice we’ve done some. magic to remove the ‘then do’ section effectively pausing code from running until the block has received it’s payload from the server such that the data can be processed further down the chain. For example you can pause a forLoop when using the cloud variables and data blocks both of which use asynchronous code execution.
You’d see the same issue if you made an api call and included code int he then do section. the loops would run before the api calls were complete most likely.
2 Likes
The Alert component is an asynchronous component which means it will not wait anyway whether it is inside a loop our not.
You can easily test this behavior by having a project with two screens. In the first screen have a button and when you click the button make it display an alert and then navigate to the other screen. You will see that the other screen shows covering the alert. This is how it works.
3 Likes
Thanks for the follow up guys. I know that the Alert is currently asynchronous but I am asking why?
I need it to not be asynchronous. So, as Jared says it would be good to explore this further. I would like, if possible, some kind of setting to make it a “modal” dialog box and stop the process until a User action happens. To have to call a recursive routine to achieve this is not the best.
1 Like
Well, as a Thinkable enthusiast, as long as there’s a solution to outcome something like an asynchronous block (as Alert is), I say “let’s not repair” something that is working. I assume that a no code approach for the users involves a lot of complicate mechanics behind, so trying to change something big as this, will result, actually in a lots of, maybe, other bugs, that will consume a lot of time to be solved later.
But this is just my opinion.
1 Like
Any blocks you add to the then do block will be executed after the main block has finished so to execute something after an action is made with the Alert keep the code blocks in the then do.
2 Likes
ps: I have expanded this into a new thread:
https://community.thunkable.com/t/asynchronous-processing-issue/1992206?u=tonyb2
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.