Renaming isn't... real? Problem with any component blocks

What?
You renamed it in the designer, then rebuilt it, re-installed it, and it retained the old name?

I would definitely call this a bug.
Unless you saved the component names in a persistent list, as opposed to a volatile one.

But why do I get “Pulsante_Margherita” instead of a code?

And for other buttons I get other names, or “button14” where I didn’t change the name, or “button 11”, I hope it’s just something that has to be fixed/addressed

@Mark, what’s your thought?

Since every button can be associated with dedicated events “when MyButton Click/ Long Click/ Touch Down/Touch Up” that uses the name of the component, it would be interesting to see if those names are properly changed when a button gets renamed, and what they return if you make them ‘talk’.

@maxb, When I create a very simple app like the one in your screenshot, the text that I see displayed in the app when I click on a button shows what we call a UUID, like the one that @actech shows in his screen shot. I do not see the name of the component. That is by design. The component block contains that UUID as a non-changing (even when the component is renamed) reference to the component.

If you are seeing the name of the component, could you please check the version of your Thunkable Live companion app? To do that, please go to your project list in the companion. You can do that from a live project by clicking the back button in the top left. In the project list, long press (i.e. click and hold) the “thunkable” text to the right of the beaver at the top of the screen until an alert appears saying which app version your are running. The current version is 88-1. If you are seeing an older version, please update via Google Play.

If you are running the latest version of the companion and are still seeing a component name rather than the UUID could you please post a link to your project and a screenshot (or video) from your running app showing the behavior that you are describing?

Thanks in advance.

-Mark

That’s very sad for me to hear as it would have drastically reduced the number of my project blocks (but maybe more computational stress on the phone?) and automation for future improvements/changes.

Is it possible to have this name thing implemented?

Live app is 88-1,
I have the project ready to share, but do I have to delete the various references to firebase and personal stuff or will it not be shared? I can’t remember

You are right about the fact that it was much easier to work with the names of the components. But in addition to this, it is necessary to replace the drop-down lists of component types with variables. Otherwise, everything will look too complicated, as on the screen scrAnyComponent

https://x.thunkable.com/projects/5cd84f23e3097f3353fdad45/project/properties/designer/

@maxb, I’d be interested in why you believe you need to have the displayed value of a component block be the name of the component in order to do what you want? Isn’t it sufficient that when you use the component block (in generic getters, setters, method calls, when blocks, etc.) that it refers uniquely to the component? Note that his remains true even when the component is renamed.

-Mark

Just so you know, you can specify the textual name of a component for any of the generic getters, setters, methods, events, etc. The one thing that is a bit confusing (and is a bug) is that you can use the textual name of a component in equality comparisons in some old projects, but not in others and not in new projects. Our intent was for those comparisons not to work, so please don’t use them, as they might stop working at some point. We do hope to add a block that allows you to get the name of a component, and at that point you’ll be able to do those comparisons safely.

-Mark

I’m not sure exactly what you mean by the above, but you can currently assign component values to variables and use those variables in any place that a component block can be used.

-Mark

Note that while you can use the textual name of a component to refer to it on the generic blocks it is generally not advisable, precisely because it won’t work if the component is renamed. It is much safer to use a real component valued block rather than the textual name. Please see my reply below for a little more on this.

-Mark

Mark, I noticed that to set the property, it is desirable to use a block, the type of which corresponds to the type of component. For example, if in the block below for a button, a label and a input to use one block with the type “Button”, then for the Label component the Text property will not be set. Therefore it is necessary to use three blocks. If the component type in the block was chosen not from the drop-down list, but by using a variable, then this would simplify the work with such algorithms by an order of magnitude. I will add this query to the desired functions.

%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

I’m not sure sure how often the capability you’re asking for is really needed, but it is duly noted! I see that you have added the feature request at https://github.com/thunkable/thunkable-issues/issues/196. Thanks!

-Mark

Mark, I added request to https://github.com/thunkable/thunkable-issues/issues/199 I would call it the universal blocks Any Component for calling methods.

It may be too powerful and functional blocks, but one such block can replace dozens and even hundreds of similar simple blocks Any Component.

Got it.

Cause I intended to set the names of the buttons to specific references, like “Button_Main_Pizza”, “Button_Second_Pizza”… “Button_Main_Hamburger”, “Button_Second_Hamburger”, I have many button that have to do the same thing but with different variables and the results have to be displayed on different design elements, so I was naming all the design elements and variables with recurring elements that the system would look for when deciding what to do (I wish I could use your terminology :smile:)

And then set firebase and variable values accordingly to the names;

If you click the “Main_Pizza” button do the “Main_” things with the variables of “Pizza” in the row named “Row_Pizza”,
right now I don’t know if I can do that with one variable.

Hope I explained myself

I don’t think this works for me, What I would like to do is to use the name of the button pressed to change variables and design elements that have that same name.

As a temporary solution, you can try the following trick: assign the button name to the TextColor or BackgroundColor or BackgroundPicture property, and when you click on the buttons, use the values ​​of these properties as the names of the buttons.

But when the user clicks the button called “Jhon”, how does the app know that the button pressed was Jhon and not Jane?

What I need is that I will insert the button’s name in a list that the user will see, so it has to be THAT EXACT name, I think I can create a workaround and have the same result but I also think that it could be done by the developers with not too much effort, to let me use the button’s name I mean, or at least I hope.

@maxb I think I understand what you’re trying to do and it makes sense to me. There are a couple of upcoming features that should help you. One is a block which would return the name of a component. That would, presumably, let you do exactly what you described. The other is the ability to add your own properties to a component, so you could, for instance, add a food property on your buttons which could have a value of “pizza” or “hamburger”. That would allow you to name your buttons whatever you like but still distinguish them. It would also allow you to distinguish buttons (or other components) that you create dynamically via the Create or Clone blocks.

What @actech was describing was a way to work around the fact that the features I mentioned don’t exist yet. For example, if you set the TextColor property of your buttons to have the same value as your button’s name, you can use that property to distinguish your buttons. It works because invalid TextColor values don’t have any effect on the color but they are saved with the component. If you happen to want to actually use the TextColor property to change your button’s text color then you can use the BackgroundColor or BackgroundPicture property instead. Note that I can’t guarantee that invalid values will always work this way (e.g. we might decide that they are an error), so I would suggest that if you use this workaround that you create a function (called, say, “GetButtonName”) which takes a button component and returns the button’s name. For now, that function would return the value of the TextColor property of the button, but you could change it to return the actual name once that block is available.

Hope this helps.

-Mark

1 Like

Thanks for the answer and everything,

could you tell me if the name component is gonna follow soon or it’s gonna take a while?

I ask so that I can decide if I should just wait for it or go back or use the workaround.

Thanks for the answer if there will be ^^

I think it’s going to take a little while.

-Mark