componentName should be TextBox, not TEXT BOX
4 Likes
It was like a âtextboxâ. So I switched to âtext boxâ. And the error continues.
1 Like
Note that the name is case-sensitive.
textbox wonât work. Use TextBox
6 Likes
Also, I suggest you increment acont after youâve set the text. Else the extension will crash as it tries to fetch a component on an invalid index
3 Likes
Thanks !!!
1 Like
By the way, you donât need to have a variable for ID, you can use Last Used ID block and increment with 1.
3 Likes
@yusufcihan , Congratulations for the great work !!!
Iâve already managed to bring the result from the database. Now Iâm thinking about how to read all the text properties of those components that were created and return them to the PHP script and write to MYSQL.
2 Likes
We could create a public list to correctly call the components.
1 Like
The extension developer has already listed a method to find out internal component names
7 Likes
I donât think this is a good idea, because available component list is different according to different builders, and because of that this extension also allows builder-special components, it would be bad to create a static list.
2 Likes
I found a strange behaviour when it comes to sprites: in this .aia included they are not removed at all from screen or memory. Is it my fault?prova.aia (20,0 KB)
1 Like
Iâm working with 250 sprites all made by the extension and they all behave like they should.
Can you show your blocks please? I canât open aia files in my phone.
2 Likes
May be you have more blocks but in these you are showing, I see thereâs no need to make the ID of the sprite a random number. Is it necessary? Why not use a fixed ID? May be that way it will work. Or save the random number in a variable and use that variable instead of the LastIDUsed block.
1 Like
Already done and I already tried with a fixed integer , with no benefit; those listed are all the blocks needed to check the component (it does not work in thunkable also). I think there is some sort of bug related to Imagesprite component only(?) because it works with e,g, button component
2 Likes
I was using an another method to delete the components, but I just noticed it behaves weird for some components, so instead of removing them from view, I changed the behavior of Remove block and now it makes the component invisible (by changing Visible property) instead of trying to remove it from view. Both methods are the same in theory, only backend was different.
Thanks for informing me about that! Remove block is now remade and I will publish the new version today which fixes that bug along with new blocks! 
(and for public source code 
)
6 Likes
Please, think carefully about this choice, the remove method frees memory and let you reuse the id, indeed a very good achievement. The visibility of each component is already managed by its properties, so now we are advised that for some components, at present, is not possible to destroy them and we can decide ourselves which method is better for our goals. Maybe in a future time you could manage to find a solution. Just an idea: you can try to contact Evans at MIT in his blog on appinventor and discuss the matter with him. He is deeply involved in developping Appinventor and a very kind person.
1 Like
Hi. Yusuf. I tested this component and I think it brings Kodular to another level.
I change all dynamic componentes by it. Kodular didnât have dynamic arrangents but I got to produce a list using it in place of Dynamic CardView.
Now I get to see Kodular as an OOP (Object Oriented).
I will continue to explore possibilities.
Thanks.
3 Likes
I think you also meant Java 
Thanks to Java, it would be impossible to make such an extension without using Javaâs features!
Thatâs the spirit! Also you can be sure about that I will continue to explore what can I do more for App Inventor!
Youâre welcome 
4 Likes