Using a variable's value in button's text

[sackboydad]

How can I take a variable's value (what's stored in the variable) and use that to st a button's text?

I need to be able to store a string to a variable (say "CAMERA 1") then I need to set a specific button's text to the string stored in the variable, rather than just the variable's name. Now, when I attempt to do that - $(custom:New_Text) - what happens when I set the button's text to $(custom:New_Text) it will show the correct value (the above "CAMERA 1", but if $custom:New_Text) changes, then because the button's text is set to a variable it will be wrong. I need to permanently set the button's text, as a string, to what's stored in $(custom:New_Text). So in the button's text entry it would be changed to CAMERA 1 rather than $(custom:New_Text).

How can I pass the variable's value rather than its reference? Thanks for any help. This is killing me :-)

[dnmeid]

That is the most basic usage of a variable. You just enter your variable name including the brackets and the dollar sign in the text box. Then the button will show whatever is stored in the variable.

For this simple use, make sure that your text is in STring mode (the small button at the right shows an "A") and that you spelled everything correct.

[sackboydad]

So.... I think I found a workaround..... If I use the TCP module and send the command:

LOCATION $(custom:Last_Button_Pressed) STYLE TEXT $(dataentry:entry_last)

It works! I just have to turn on the TCP Listener. since it's on the same Mac I just set the TCP module to 127.0.0.1. Both variables are passed as text to the TCP module. It does exactly what I want.... it places the actual text into the button's text field. Wish I didn't have to do this. Companion should have a way to pass a variable by value rather than reference. This can't be the only place someone might want to do that.

[dnmeid]

Using the http API in deed is a usable workaround, but this is not recommended either because any direct changes of button properties, no matter how, are not recommended. We are not decided yet how long we keep the according actions and API endpoints or if we drop them.

Companion should have a way to pass a variable by value rather than reference

Companion always passes variables by value and not by reference, the point is that the action itself does not interpret the variable and just passes whatever you type in the option.

This can't be the only place someone might want to do that.

Correct, sometimes people ask for the possibility to directly setting button properties. As this is the most obvious option usually they think it is the best option. But it is not. It makes your configuration unmanageable quite fast. Now that you have found a workaround, you will use it and you will remember my warnings later. You will change this programming style sooner or later.

[sackboydad]

I'm not using the HTTP API, I'm using the TCP one (but maybe you're using that in a generic fashion).

Sorry I should have emphasized that it's the action that would be nice to have a choice on whether or not to place the value or its value.

I agree with you about the proper way to do stuff in regards to setting button parameters directly. My needs are very specific. Our church has specific shots for its 5 cameras. Those shots are used by all (only 3 of us) directors. The names of those shots are set inside the companion action. On each camera there are usually 6 camera presets that aren't used normally and they just have the preset number in the button. One of my directors really likes to name the "temporary" buttons but I'm not crazy about him going into Companion. So when I found the DataEntry module and its keyboard I had the idea that if I made it easy to rename the buttons without someone having to go into Companion it would solve both problems: Temporary buttons can be renamed and it keeps people out of Companion.

I've had people tell me I need to make an array of every single button, etc. I just don't want to go to that much trouble. From my perspective, that is WAAAYYYY more management than I want to do. In addition, it's not uncommon for me to move buttons around a page, a different page or a different surface. In fact, the biggest downside to moving are the broken dependancies. I have many places where one button mimics another button (can't remember the action and feedback names to do that at the moment). When I do that and I'm referencing a specific button (1/4/3 for instance), I can never move the button the others are referencing without having to change every singe other button to point to the location of the changed button(s). I can't begin to describe how much I would like companion to show a "dependancies" list -- or at the very least have a warning if you move a button that other buttons are dependent on, then gives you the opportunity to update the buttons that are dependent.

Anyway ..... sorry got off on a tangent there :-). To me, allowing the end user to rename certain buttons by changing the text field doesn't bother me.

I do really appreciate you helping me out both here and inside FB!

[dnmeid]

I see you are already at the point where you realize why direct changes become unmanageable very fast.
Now that you have only 6 presets that you want to rename dynamically, simply create 6 variables like name_preset_1 ... name__preset_6
Then put these variables in your button texts and then you simply change the content of the according variable.
You can move the button later and everything keeps working and you don't have to track any references.

[sackboydad]

Ok Dorion, after a long time to think it over, I now 100% see why you're right regarding arrays. I've played with it and I almost understand how to make it work.

I'm using the dataentry module (is that yours? I can't remember).

I have 5 cameras, we use 40 presets each (20 each with 2 different worship services). When an operator initiates a "I want to change the button label" (meaning it's not important how that actually happens) I immediately want the companion page that has the dataentry module keyboard to come up. I want to have what the button already has in it displayed on a "keyboard" button.

They type what they want (and it's shown in the "keyboard" button as they type. When they press RETURN, I want the button they said they wanted to modify updated with the new text. Lastly I want the keyboard to go away and return the stream deck to the page they were last on.

I could go and use 5 variables each with an array of 40 items. $(custom:Camera1_Presets), $(custom:Camera2_Presets) and so on. Or should I use one single array for all of it? I think a long time ago they were called 3 dimensional arrays?

So, user selects button to change. I have to pass that button's text (or reference the array position) so that the dataentry keyboard can show what the button already looks like, right? then, when they've made their change and they keyboard takes them back to the page they were on, I simply have to use the $(dataentry:entry_raw) variable inside the arr=$(custom:Presets_Cam1); arr[] = $(dataentry:entry_raw); arr command, right?

So I have no idea how to setup an array in a single variable to handle all five cameras each with 40 presets. Or maybe in this case it's better to use 5 variables with a simpler array?

Lastly (I think I said that an hour ago 😬) In the action when the person initiates renaming the button (set the variable that says which button needs to be changed, then change the surface page to the dataentry keyboard. How do I make companion "wait" for the keyboard to be finished before proceeding to the next steps?

Steps:
<decide if the "rename button key" is turned on (true or false)>
<change some kind of variable to indicate which Camera & preset we're modifying so dataentry keyboard can display what's in the button already>
<change some kind of variable so companion knows which page to go back to after the RETURN key is pressed on the "keyboard"

--after ENTER is pressed on keyboard, use previously stored variable so companion knows which page to return to
<contuning in the original button's action, take the data from $(dataentry:entry_raw) and stick it back in whatever kind of array we're using>

But how does the button's action know to "wait" for the keyboard to close, return to its page and know to continue?

I really do appreciate your help and I really have tried to figure this out.