componentName should be
It was like a ‘textbox’. So I switched to ‘text box’. And the error continues.
Note that the name is case-sensitive.
textbox won’t work. Use
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
By the way, you don’t need to have a variable for ID, you can use Last Used ID block and increment with 1.
@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.
We could create a public list to correctly call the components.
The extension developer has already listed a method to find out internal component names
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.
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)
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.
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.
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
Ok, let’s wait for @yusufcihan to give his input about this.
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 )
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.
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.
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!