I m geting crazy, each time i close thunkable all the backgrounds that i had set in buttons with blocks are like this:
Hi @Leito did you by any chance delete or rename the image you were using here?
Do you know if your project has perhaps gone over the 50MB limit??
Nope, when i see the details of the app figures Size 8 Mb.
And i didnt delete or rename anything.
if i set everything there are no problem but If I go out thunkable and come back in, i see that
I think this shows there would be an advantage in allowing Background Pictures to be associated with object reference to picture files, as opposed to be forcibly and permanently locked with an object that can only take the value of image files entered as asset.
By allowing file names to be made element of a list, Leito program could be simply
from TituloClassicos set Background Picture to in list app PictureList get # index
without all those extra “if then if” construct.
(and while I have you attention, can we have an update on the API 28 Classic compiler fix? That one starts to get a bit long in the tooth…)
You can put text block, inside it you write
For example: car.png
Thanks you very much for that tip!
Thanks!! I will try to do this but how can i put each specific image? i have to change the name of the pictures?
One of the options of how to solve your problem
That is interesting. The fact that you cannot remove the component on the right of a picture assignation threw me off, I didn’t know you could override with another component.
That said, how can you refer to files that are passed as assets? Just with their name, without the need of any path, is that adequate?
(That said, it would be nice to be able to pull out the name of the file as tiles, as opposed to having to type them in a text block.)
Well, with the tip provided by @Abdelrahman1 , it seems you could put the name of all the files in a list, and then simply fetch it using the ‘index’ (that means, no need for 50 “if esle if”).
I haven’t tested it myself, but have no reason to believe it wouldn’t work.
I’m not sure I fully understand you - but there are a few ways of specifying the picture property of components such as this.
- The default shadow block gives instant access to all the images that have been uploaded to the project. This has the added benefit of reducing typos when specifying images.
- A conventional text block can also be used if you know if the exact name of the file, or precise file path, that you want to display:
- A list block can be use to store a list of image names (static or dynamic) and be assigned to the picture property of a component.
EDIT @Abdelrahman1 only saw your suggestion after I posted this - thanks for pointing this out!
Thanks to everyone! I solved this thanks to you!
@domhnallohanlon Dom, i would like to know what i have to do now about Adcelerator, i asked in other post 2 days ago but i didint have answer
That is the little problem, actually. The default shadow block cannot be removed, dragged away or duplicated. It can be replaced by clicking something else in its place, and that is where is becomes less intuitive, because that is a departure form the way all other blocks arrangement can be edited.
Granted that this is how math functions appear as default (with a default block that cannot be removed but can be over-written)
Perhaps there is a reason for it, and that X cannot deal with instances of green file reference tiles outside of an image or a sound assignment, but then again, this actually prevents someone from building a list of asset files directly, everything would have to be typed manually.
What would be really useful is if the asset files would appear as variables, in the Variables tile selector. Perhaps a subset called “Asset files” although this could be confusing for people not having any asset files to have a menu that would be empty of any tiles.
Here is an illustration:
I dragged the modulo function out of the tile selection menu. By default, it shows ‘remainder of 64 and 10’. The original “10” is overrode with a number math tile, and set it to the original value 10.
The original “64” I over-typed with the value 12.
Notice how different they look? The pale blue 12 cannot be copied out or dragged away. But if I drag away the one with “10”, a pale blue, irremovable “10” default block would appear.
Essentially, this means that there are two instances of number representation in the system, those that can be dragged or duplicated, and those that cannot. I suggest that this dual representation is a slight burden on the system on your end; but also could be a source of confusion for users.