I tested it in Design and it worked. I have a hard time believing it would not work as well operationally.
1 Like
The flashing bit could be anything besides Thunkable.
Suppose for instance that you have a loop that counts from 1 to 1 million and displays the number. Since the loop does only that, then it will be counting massively fast. But there is no way the screen display controller will be able to cope with that; it normally refreshes the screen something like 30 times per second; which is supposed to be adequate for human vision already.
Let’s assume that the loop would count to 1 million in 10 seconds. At 30 frames per second, you can expect to see 3000 being displayed, then the next number is probably going to be in the 6000 range, 1/30 of a second later.
What is happening is that the Thunkable process is just putting a number requesting it to be displayed, and the screen controller determines that it needs to turn this pixel on, that one off, these two on, and so on, to make the image that corresponds to the number to display. But it is not even finished processing that display that it gets a new request from your app to display something else.
Essentially, you can expect that the operating system is going to put a limit to this, taking requests up to a moment, then closing the door on new information until it is finished processing the one that was already submitted. Meanwhile, the requests for a new display just overwrite one another until the screen controller states that it is finished with the previous image and is now ready for a new one.
This may make some transition appear abrupt.
You can ease up the transition by making your columns uniform in background colour, and fading the images, but that is a lot of work. And may produce inconsistant results as a function of the particular device that is running it. Do not lose too much sleep over that yet, concentrate on your end product. If this flashing thing is an annoyance and your program is ready, we’ll have time to revisit and see if something can be done; but do not be afraid to experiment and try things in the meantime.
And yes, the ‘any button’ approach is definitely another way, one that I was saving for perhaps later. The fact you found about it on your own means that you are ready to fly.
2 Likes
My brain will explote! i thought that i had already done but no…
I m doing something bad with up and down buttons, in some cases i need that both be hide, when the instructions need just one screen, and in other just the down but i need to reset always because if the user leaves in the last page then the down button is hide
A big thanks you very much for you! i m still confuse about any component and simple buttons; do you recomend any always or just in specific cases, because if i count the blocks, sometimes any components need more blocks
1 Like
The ‘any component’ approach works best if you regroup activities, and have a single call. The way you set it up, the number of blocks is about the same.
But what you could do is, instead of calling AnyPage and SetImage in each of the section based on the value of the component, is to simply set a local variable “local_index” to 1, or 2 (or 3 etc).
And then, at the end of the “if” sequence (which would be better if is was “if then/else if” because right now, you are going to make all the other tests even if component = Buton_TengoBercoClassico; I mean if component IS Buton_TengoBercoClassico, that is pretty much settled, you do not need to check it for being Buton_QuienSOYClassicos, right?) then you call AnyPage and SetImage with the argument “local_index” (which would have been set to 1, 2, 3…).
You can also save some block by having AnyPage call SetImage, instead of calling it directly. AnyPage already knows the value of index, so can be passing it along, right?
Yes, you are working very hard, you are learning all the tricks in the book.
As for the showing/hiding of the buttons, that is some additional logic you need to build at load time, when setting the page. When the chapter is loaded (with the “Set” function) you can immediately check how many elements are in the CurrentChapter list. If the number of pages is >1, you need the down button to be visible. If the number of page is 1, then you evidently do not need the DOWN and can make it invisible. Function “Set” would be a good place to decide on and control the initial visibility of the DOWN button.
2 Likes
I had almost didnt sleep thinking whats was wrong, because in the tester it was function but not in the app, the problem was this!! after 8 hours tryng different things, i founded and i fixed, now i every button works as i want 
here is a picture of my mistake and then the correct one 
really thanks for everything! i will never forget this
now i m completing all the texts there are a lot… but the functions now are perfect.
when the app be ready you will be the first i will notify, really thanks to you
Now the only screen that is slowly when i navigate is other one in where i have random generate buttons, i have 500 blocks there, i dont know wich is the recomendable blocks quantity per screen. Do you thing that i should create another screen? And divide to the half?
I am not that much aware of the limitations in the block count in X. I know it is less than what Classic used to support (and presently my app will not compile as the API 28 compiler in classic cannot handle more than 1/3 what it used to, and I was already brushing the limit with my 7000 blocks app).
500 blocks would be average in Classic; in X I have seen people reporting the system was struggling with perhaps less than that.
But in all cases, less is better. The idea is to mercilessly optimize and reuse blocks as much as possible. That means looking for places where the same thing is done to different values, and to instead make that processing a stand-alone function called with different arguments, exactly as we have done with the page index.
Why do you need random generate buttons (i.e. more than one)?
1 Like
There already are a few things that can be done to reduce block count.
Notice that you are calling to get a random element and remove from the same JugedoresRey list 4 times?
That whole sequence could be a single function called at 4 different places, and you would save something like 16 blocks.
Also, your Buton_ListoReyManda.Click event is doing the same thing 3 times: checking for the length of Text_input28 and inserting something at random. One test would be enough, and if you need to add something 3 times, a ‘repeat’ statement would avoid having to make copies of the same statement.
In your ShowYoNunce (as well as ShowSPINSHOT) you are multiplying the length of a list by 1.
Why this useless operation?
1 Like
Thanks Vincent The text_input28 was a mistake and multiplyng the lenght by 1 is another huge one 
Thanks for everything, i m completing the texts with the function that you told me; then i will divide this screen in 2 to get speed in buttons clicks 
i learned a lot with you! i have a lot to learn yet but i m working in that.
I know this isnt helpful. I am just starting to feel the pain. It started around 600 blocks. 
the cost of dynamic complicated content
seriously though. If this platform didn’t exist, neither would my apps. I CAN’T CODE AT ALL! So currently, as long as it doesn’t take a minute a block I’m good. Hopefully there will be someway to streamline this for PRO users. Maybe a way to optimize network channels for those who are paying as a way to deal with the massive amount of network information that is going on?
idk if something happened recently, but it feels like something has sped up. Not when i am switching between screens in the editor, but once i’ve been on the same screen with the block editor for a few minutes. things really pick up speed. my largest screen has 830 blocks (3139 total in the app). the longest I have to wait is about 5-10 seconds unless I am creating or changing the name of a variable. this takes longer because the changes are more widespread
2 Likes