Hi,
I have few flex repeaters that have almost 44 instances on each of them. I created these instances and their related parameters by using a script and assigning them to the instance property of the flex repeater.
But, I need to bind every parameter in the flex repeater instance to the a the value of a radio button on the same view. Currently, I'm doing this by creating the binding manually on the parameter of one of the instances and them using copy-paste binding to have the same binding on other instances as well. This is very repeatative task. Is there a way to do this by writing a script?
If this is not possible, I might go with using a message handler to update the parameter on the view directly which is getting rendered on the flex repeater on value change of the radio button.
Use custom properties to expose the bindings outside of the flex repeater:
-
Bind the value of the radio button to a custom property on the flex repeater. This will be a single source of truth for the flex repeater.
-
Bring in all other variables that are dependent on the radio button to a custom property and create bindings on each of these values in a form that will be useful in your instance generation script. This has the added bonus of making debug of these values much easier as opposed to having the bindings buried in the flex repeater instances.
-
If necessary, add a change script on the newly added radio button custom value to update the bindings and/or re-generate the flex repeater instances.
Since you already have the instance generation script it should just take a little tweaking of the same script depending on the radio button value.
1 Like
I think I may have given the wrong impression. The instance generation script is only run once during development and is not executed as part of the project at runtime. However, the radio button values can change in the UI, and those changes need to be reflected in the Flex Repeater instances.
Assuming there’s a pattern, you could script the binding creation outside of Ignition by modifying the view.json.
- Shift-click on the view and Copy as JSON
- Paste into an editor
- Use an external tool/script to create the bindings you want (use the existing bindings as a reference)
- Paste the
view.json back into Ignition when you’re done.
44 is a lot, I’d be reconsidering my design if I had to manually do 44 of anything.
4 Likes
On a related note though, I do wish there was a way to multi select and paste bindings so all selected components would get the same binding. Most of the time it's not needed but there's been a few times where it would have been nice especially on the enabled property where many times you'll have multiple buttons or fields relying on the same binding (or very similar where you only need to change a small variable in each).
6 Likes
Just passing on a convenient workflow tip because sometimes you may want to copy a few bindings and maybe copy some other stuff that would blow away your binding copy.
If you copy a binding and then paste into a text editor it will have json that represents the binding. You can do this to store a bunch of bindings in a way that you can grab them later. You can copy the json from your text editor and “paste binding” to apply it to a property.
Other people have given good tips on structuring your bindings in good ways and I generally agree with that.
2 Likes
That’s really cool, sounds like there’s a potential for some AHK tooling.
1 Like
It probably wouldn’t be a good idea to having bindings on anything that’s dynamically generated anyway. I could be wrong, but I’m pretty sure if you create a binding on a specific instance, and then a script changes or moves that instance, the binding stays with the instance number. Like say the instances are an array. You have instance 0, 1, 2, etc. You put bindings on all those instances. A script now inserts a new instance between 1 and 2 and now you have instances 0,1,2, and 3. What was instance 2 is now 3, but the bindings don’t “move” with it, because it’s not actually “moving,” the script is re-creating it. Because bindings don’t move as things are added and removed and shuffled around in an array, you can easily end up in a scenario where your instances have the wrong bindings.
Bind the radio buttons to session.custom props, and then just pass to the flex repeater instances which session.custom prop it should be using in it's internal binding.
1 Like
What are your radio buttons connected to? Are they connected to a tag?
When I do any kind of templating, I avoid needing to have bindings on input parameters to templates. If it’s connecting to a tag, I make the input parameter the path to that tag and handle the bindings within the template itself.
Whatever your radio buttons control, I wouldn’t try to directly control them with a binding on a parameter, but use parameters to give your templates the information they need to control what the radio button is controlling so they can use their internal bindings instead.
4 Likes
Thanks for the tip. The radio buttons are not connected to a tag; they represent the different levels of a warehouse rack shown on the screen. So, when I select one of the radio buttons, the UI displays different rack locations for that level in the warehouse.
I have decided not to use bindings on the Flex Repeater instances. Instead, I will run a script to recreate the instances and assign the required parameters whenever the radio button value changes.
1 Like
