How to set binding via scripts?
I need markers have to change its colors when something happens (Alarm for example)
I know how to set binding via hands, but I need to do it via script! Please help me ASAP
I did it by myself)
If someone has the same trouble as I did, so I can tell You how I did it
Hey israc, I have the same issue where I am trying to set binding via script, but am not successful. Can you please share how you set a binding via script? I am interested in setting a tag binding via script. Thanks
If You want some actions when a new alarm comes, then create a new expression tag (select active alarms by function system.alarm.queryStatus). Then make a Tag Event Script on this tag when value changes its state. In this script call the Gateway Script, which (as I did: I created a new memory boolean tag) sets a Boolean tag to true, then go to perspective and check if this Boolean tag is true, then run script, which goes through all your markers and sets on desired marker color to red (if a New alarm appeared) and set this tag to false
The idea is:
New Alarm —> Gateway Script —> Boolean Tag = True —> Perpsective: run script —> set Boolean tag to False
Hope it helps You
Thanks for the info. But, I was actually more interested in programmatically setting up a tag binding in Python code. I am trying to populate a table with data that changes (based on tags) and some of the cells need to be bound to the tag that it reads the value from. I have a script on the onStartup function of the table which loads data from a dataset and populates the table with it. However, I need a way to set up the bindings on the values in the table that update. Thanks
Yes. I was interested in this possibility also, but the best solution for me was to update states when something happens (tag change/new alarm etc).
The short version is basically that you can’t - there’s no way to dynamically create bindings in a running Perspective session. If you need dynamic project resource creation, technically you can do that from the filesystem in 8.0, since Perspective resources are just JSON files - but, you’re entirely on your own in terms of discovering the format and creating valid views.
Long term, it’s possible we’ll expose a more first-class way to create dynamic views - perhaps something akin to Webdev’s Python resource handlers, but no guarantees.
Regardless, it’s probably that dynamically creating bindings isn’t the only solution to your problem; just as @iscrac was able to work around his issue with a different solution. From what you describe, you could have a single expression structure binding bound to each of your tag values. Then add a transform that will extract each value from the pair and dynamically construct the data to display on the table; something akin to this:
(Using an expression structure binding, you don’t have to set up any polling; the expression structure binding will be automatically notified of any changes to the subscribed tags.)
Thanks for the response and the information. I ended up building some code outside of Perspective to generate some JSON which I could then just copy and paste back into Perspective. The only lament is, if the data set changes, I will need to regenerate the JSON and copy and paste it back into Perspective. Luckily, this data set will likely never change.
Any update on allowing programatic binding of values via scripting? we need to add markers in a map component where each marker icon color must change based on a binding which reads the tag status via modbus.
@nminchin gave some pointers on how to achieve that:
I think this could help you
The short answer is no.
The feature I described would also not be ‘programmatic binding of values via scripting’, really. That’s a whole different kettle of fish. What I’m describing is a kind of ‘server-side rendering’ for views, where a Python method is called when visiting a page and returns the definition of a view.
That’s also not a confirmed feature by any means; it’s just an idea we had kicking around the office. As @pascal.fragnoud mentioned, if it’s possible to “precompute” these bindings then that’s going to be both more performant and easier to work with…plus it works now, not at some vague future time.