Misused when any Taste.Klick. If you have many buttons, you need to use a different argument. You should do your work by missing some buttons from triggering when any Taste.Klick.
Let's say you have 500 buttons, 10 of which you are going to trigger alone, run the rest with when any Taste.Klick, but specify those buttons at when any Taste.Klick.
for example, I am calling functions of 70 individual buttons with the following block. The article is in german and sample codes, but nothing changes.
if some specific button's click event is defined seperately, you can excluded it from the any button click event by using if (not already handled) then ...
no need to check if (component !==some specific button)
I pulled a thread from the blocks area and started to expand it.
It's still unraveling ...
It's the set_visibility procedure, with 797 blocks.
(It was too big to upload to this board, when halfway expanded.)
Here's the draggable compacted form:
This appears to be an explicitly coded recursive visibility management scheme covering a tree of nested Arrangements, with +/- Labels (Buttons?)
I have yet to encounter any tables of components in the Blocks workspace.
This procedure might benefit from being table-driven, from a component table with columns:
@Profi & @Kevinkun thanks for your effort and input. I appreciate it.
But I have to say that your findings are in my opinion not the reason (or at least not the only reason) for the DX error, as i can build my apk with all those finding being enabled.
Hi @ABG , yes, your observation is completely right. It is a procedure that I call to show or hide certain screen elements, some of them even nested.
But i have to say, the whole procedure is completely enabled - and my APK still builds!
So this procedure itself, stand-alone, seems not a problem.
KR, Oli
So I've looked into it on our end, and the issue appears to be that the DX process runs out of memory as we only give it about 2 GB of RAM. When I increased the amount of RAM to 3 GB it built fine.
Evan, thank you!
Does that mean that now 3GB RAM ist the new setting?
And if so, does that mean MY poor app lead to that increase from 2 to 3GB?
KR, Oli
No, we have not adjusted this in production. This was just using App Inventor built locally to understand what was going on. I need to talk with our team about whether this should be adjusted in production.
Hi Evan (@ewpatton) , i want to check in on that topic again. A month ago you said that my project failed to build b/o 2GB RAM running out, after increasing it to 3GB it worked.
I have been able to work on my project for the last weeks sucessfully, the DX error did not appear anymore.
Did you increase the RAM in production too?
KR, Oliver
We've replaced the build server instances with some newer ones that should be more efficient, but we're still keeping the cap on memory usage per build to 2 GB (each buildserver tries to serve up to 30 users at a time).
