I have a large program that has currently 8500 blocks. At one point I had 10,000. I reduced it by making some blocks generic and looping them. However, there seems to be a limit to this. I reached a point where just adding one more block to any loop causes a compiler fail. I tried this with different loops, and it is definitely related to the total number of loops, not the particular function.
Here is a typical example. I'm using a list to select the specific block, of which there are 16:
Otherwise it is a huge array of 128 separate blocks. I have many similar pieces of code like this, which is why I had 10,000 total. It was stable at 10,000, but crashes when I try to add even one more loop to reduce the number of blocks. Is there a way to know the limit of individual blocks vs. loops?
Thanks, can you point me to an example?
All the components seem to be similar. What do you store in these components? Can't you make fewer components and only change the data that is displayed to them?
There is no specific limit. Everything affects DX error. The number of blocks, the number of components and probably many other things.
They are individual text boxes. All are on the screen at the same time.
Exactly how many fields are there?
I'm changing the background color as to highlight certain values of the text in the boxes.
About 200. I din;t have an exact count.
It has worked well until I added a few more things recently
It looks for now that I have to recognize I am close to a limit and experiment with what works and what doesn't What is frustrating is that it always works in the companion.
This is bad app planning. 200 fields no man is able to see at the same time. Make the app more human-friendly and display less data simultaneously. Divide the data e.g. into sensors or something else. You will have fewer components and automatically fewer blocks. Otherwise, it's a blind alley. Another way is to split the app to have several screens. But not 20 
.
Yes, it's a compilation problem. The project is too heavy for the compiler. The compiler does not have enough memory to compile your app. You can move the project to another server. There is more memory allocated there, but there is also a limit.
https://code.appinventor.mit.edu/
They are on different screens, and it is not unreadable to the user. Quite the contrary, it makes perfect sense.
Does the user enter data there? Are they read-only? Why don't you use a table view to show the data like this?
I tried both //code and //ai2. I crash both of them. 
In the beginning this worked well, and the table add-ons were fussy. Back then I tried "Taula's Table", I think it was called. But now I may have outgrown my method.
Read only. they are labels not text boxes.
I'm talking about extending the table view.
Another idea is to display data at a time, only for one battery.
Instead of showing data in multiple labels, you can also use a chart component.
It is the comparative feature that makes this useful. Someone can instantly spot the troublesome battery and then focus on the details.
In the above example one battery is long past its age limit, and highlighted in red.
