Hi Thunkers!
Maybe I found a bug or another “by design time-sync issue” when using the “for each” blocks with app variables different from the standard “j”.
Look the blocks below, in the internal loop I used the app variable “counter” to insert in the list “result_list”, and the expect is to have at end of loops: a1, a2, a3, b1, b2, b3, c1, c2 and c3.
But the result is just a, a, a, b, b, b, c, c, c it means the variable “counter” was not updated:
Any idea what is going on?
Regards,
Paulo Vaz
It looks like you initialized app variable counter twice: once on its own and once within the loop block. Try changing the loop variable to i or j (one of the default counter variables built-in to the loop block) and it should work.
If that doesn’t fix it, post a link to your project.
@tatiang , as far I know it’s impossible to use an app variable without initialize it.
So, how to use other variables instead default J in the “for each” block? Please note I have 2 loops nested.
As in this example, if I need 2 or more nested loops, I’ll need distinct variables, so, sounds like a Thunkable bug for me.
I have a project that have 3 nested loops… so I create this small example just to demonstrate the point here…
Project Link: Thunkable
this is weird. the setup below doesnt even show anything in my list viewer:
however if i create a dummy variable by defining a function (to be discarded later) that uses an input parameter of k - and use k as the innermost loop variable, it works!
here’s my project:
https://x.thunkable.com/copy/4c83bc818a9bfefea7f4ef649c532595
Yes, looks we have a bug, despite the workaround you found, this must be fixed…
I think is related the way Thunkable deals with the app versus “internal” variables.
What do you think about open a bug report?
i can do that.
It’s not a bug. You should not use app variables that you initialize yourself. You need to click on the j and from the menu rename it to what you want. It should show in the blocks as the name only without the preceding app variable.
This will definitely work.
I agree. This is not technically a bug. It’s the way Thunkable is intended to be used… not necessarily the best way it could be configured but it’s intentional, I believe. The loop block has its own internal variables that you need to use.
Again I found a non documented situation that creates lots of time waste trying to figure out what is happening.
If the use of app variables is a problem in case, so the component must to changed for one of this:
With all me respect to Thunkable team, but It’s hard to work, trying guess when is your fault or when is a “by design special limitation of use” of a non documented item.
I’ll insist to treat this situation as a BUG to force change the component for one of the above options, or at least explain this in the Documents site!
Absolutely. Thunkable is a product that requires that you learn a few of the “ins and outs” before you really have a good grasp for how to use it well and successfully. I’ve been doing what I can as a user to suggest better documentation (believe it or not, the documentation has been improved since I started using Thunkable but it has a ways to go) and tutorials, including making some myself for the community.
I think the more the staff hear from us that the documentation needs to be improved, the better the chances are to get that done. And little tweaks like this – where you suggest not allowing app variables to be selected in loop blocks – are important for keeping this an easy-to-use product.
personally, i agree with you. if you can use a loop variable in a join_text box as a if it were regular variable, why can’t it work the other way?
I don’t think it’s a BUG but let’s not fight on terminologies here.
In every platform you will have best practices and all what you really need is somewhere to have such guidelines listed.
One good example is the use of Thunkable Lists in Firebase. Thunkable has included in its documentation a best practice approach but if you don’t follow it you’ll find that it still works. The only thing you could risk by not following the suggested approach is the fact that you can’t be certain if your app will continue to work without breaking due to not following the guidelines.
At the moment, the best you can do is to follow the undocumented guidelines about variables inside loops. This will allow your app to show expected results.
Meanwhile, add a request to enhance/update the documentation.
We have heard and listened! We are currently hiring for 2 educational people to start creating the content and padding the docs.
I can’t wait till we find the right person!!
I’d you know a good candidate send them our way!!
In my humble opinion, a powerful product like Thunkable shouldn’t leave any gaps for developers to make mistakes (and avoid wasting time). This would be better than creating documents to explain what NOT to do…
My point here is for the staff is:
or…
or at least (for now)…
It’s not, therefore, a fight here, but rather, everyone looking for the best way to help the product improve!
I think the time you spend here for free helping people can and should be saved if we have a better product and a better documentation!
And yes, I changed my code to follow the workaround you and @tatiang find, but I think there are some learned lessons for all here… THANK YOU ALL, as usual very very responsive!
It’s OK to have different opinions. We are not supposed to have the same opinion at all.
For me, there must be a reason why the loop blocks comes with platform generated variables such as i and j instead of using the normal variable.
If the user declared/initialized variables would work then why such variables are generated automatically and added to the list of variables once you select the block from the control drawer.
You are right in the sense of making it clear why we should not mix them though.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
