Edit: this problem only occurs in the Thunkable Live viewer. When I download to iOS, it works as expected (i.e. the device vibrates when the Screen opens/starts).
I am designing a student directory app and I’ve been able to get my photo thumbnails to clone when the Screen opens so that I have 5 per row. This was working fine until just recently. Now, I have a Screen (the one with the clone commands) that isn’t responding to “When [Screen] Opens” or “When [Screen] Starts” commands. I’m also using Top Tab Navigation, if it makes a difference.
Those commands work fine in other Screens within the project but not with the clone grid Screen. I’ve been using a simple When [Screen] Opens—>Vibrate to test this. I even disabled all of the commands except that simple 2 block statement and it still didn’t work in that particular Screen.
Is it possible for a Screen to get corrupted? Fortunately, I made a backup copy not too long ago but I’d love to solve the mystery of why this just stopped working.
On a side note, is it common for projects to get bloated and slow? That same clone grid Screen is sluggish when I try to drag blocks around. I probably have 250 blocks. I suspect it’s slow because it’s constantly compiling everything with every little change. I wish there was a way to turn that off and make edits and then turn the compiling back on.
If you give a link to the project, then I will try to explain the problems with the screen.
As for the slow operation of blocks in the block editor, there is no solution to this problem yet. But you can increase the productivity of the block editor by reducing the total number of blocks on it, moving initialization blocks of variables and functions that do not work with UI components to a separate screen.
See scrInit (moving initialization blocks of variables to a separate screen), scrTitle and scrGlobalFunction (moving function that do not work with UI components to a separate screen) in ACtech demo project
Thanks for your advice and for the offer to help. I decided to simplify the code a bit which seems to be helping.
And I discovered that the buttons only clone in Thunkable Live (TL) when I set the code to When [Screen] Opens. If I use When [Screen] Starts, it works when downloaded but not when previewed in TL.
Here’s the code with it now set to When [Screen] Opens:
Your blocks do not look like a reliable solution, because, firstly, you do not check for errors, and secondly, use asynchronous blocks (Clone and GetCell) inside the loop, which in itself is a source of errors.
The block below works in Live when Starts the screen. So, the error is in your blocks.
Please note that in this example, the asynchronous block also works in a loop, but in this case it is valid and does not cause problems, because the asynchronous block works in an asynchronous context. And in your example, an asynchronous block works in a synchronous context.
I was wondering about that. I figured the spreadsheet calls didn’t have time to complete. I tried adding a Wait block at the bottom of everything but that didn’t solve it.
I assume the difference you’re pointing out above is that the “from Label” block is outside of the loop, correct? Whereas I have it inside of the loop with the spreadsheet blocks.
I’m brand new to Thunkable so still learning how this all works. Do you have a link to an example of how to handle errors? I tried searching the forums but the info is old and doesn’t seem to show how to do this. The only thing I could think of was to set Label text to error but that didn’t give me any useful info. I assume the error block returns text. How do you typically handle that result?
In violet blocks (and not only) there is a block “error”. If this block is not empty, then obviously it contains an error message. If an error occurs while executing a block, this may affect all remaining blocks. In many cases, it makes no sense to execute the remaining blocks if an error occurs. For this reason, always check for the presence of text in the “error” block as shown below (It is not necessary to use the Alert component to display error messages).
Errors are different. If some errors occur, the application can continue to work, but if other errors occur, there is no sense in continuing to work. For example, if the data has not been read from AirTable, then there is no point in working further if all other actions should occur with this data.
And in each case, you need to imagine what errors can occur and what to do when they occur. At first it will be difficult to understand, but with experience you will feel more confident.
As for asynchronous blocks, you need to take into account the fact that these blocks do not have to be executed sequentially. Which block will execute faster, such a block will execute earlier. If a certain order is needed, then the operation of asynchronous blocks must be synchronized or, after their execution, the necessary ordering of the data is performed. There is also information about this in my course.Thunkable X Basic Programming Course
Again, very helpful! And I get what you’re saying about synchronous vs. asynchronous commands. I’ll add some error handling now that I have an example of that.
