[Question] Adding tag properties?

New tag’s parameters management in UDT is a great new feature with the possibility to read/write them by script with the dynamic UDT reconfiguration. :clap:
Thanks a lot fot that.

In tag property binding we can put multiple {parameter}. In the beta, the binding concatenate only the parameter or do you plan anything else ? expression of parameters ?

My last frustration is the impossibility to add user properties for tag (especially tags od UDT).
We often use the documentation property of the tags to store lots of information related to the tag in a JSON format, but it’s not very handy to edit and manipulate or reference.
The ability to add tag properties or a new JSON/Dictionnary tag property could be a great value for us.

While there isn’t a interface in the normal Tag Editor now, if you right click a tag and select Edit (raw), the raw editor will allow you to add whatever property you want to any tag. For example, in the below screenshot, you can see that I have added a property of GarthAdded to the Integer tag:

I am then able to bind anything to that property by addressing it by the property like Integer.GarthAdded:

This UI is very finicky, and you need to get the cursor placement just right to make the + show up, but it is there and should allow you to try it out.


Right now the binding is limited to “template string” involving parameters. This decision was made because we though full expression bindings for each property would lead to a troubleshooting nightmare, though we could be wrong.

For your other question: We will add full support for custom properties at some point- hopefully soon. As Garth pointed out, there is currently no restriction on what can be created through manipulating the tag definition, but I think that’s more of a side effect than a first class feature.

I believe we’ve talked about allowing parameters to be bound to full expressions. Since parameter references now work like standard expression references in a tag, and all changes are much more fine grained in their impact, this would be very powerful and probably not too harsh on the system.

Thanks @ggross, @Colby.Clegg for all these clarifications.

I had guessed there was some magic around the Raw Tag Editor but the new property created was not applied to the standard tag editor. Please keep me updated when the support for custom properties will be full featured in the beta.

A last question,properties types would be the same as parameters types, ie String, Interger, Double, or you plan to add other types ? (Document type for example to store more adaptable and flexible values) ?

To summary, from the script API point of view,
read/write to path/to/udt_instance.parameter and path/to/udt_instance/tag.property are allowed
and path/to/udt_instance.parameter and path/to/udt_instance/tag.property can be used in vision component bindings.

Inside UDT Data type, tag’s standart property can be binded to {parameter1}{parameter2}, as well as tag’s custom properties can be binded to {parameter1}{parameter2} ?
Is it possible to add binding with a relative reference to another udt_tag.property inside the datatype ?

Right now, I wouldn’t trust anything other than Strings in a custom tag property. While Integers will work, there isn’t a clear definition of the data type other than the JSON data is passing in an Integer. There isn’t any logic on the backend to evaluate it as such. As Colby mentioned, while properties are allowed to be defined, it is more of a side effect of how the system was designed rather than an intended feature. There are plans to make this a first class feature, but it may not be as user friendly as you would like for the initial 8.0 release.

As for the second part of your question, it hasn’t yet been tested because of the status of the feature noted above. My main concerns would be it will likely be easy to get into a recursive state should it be possible and potentially lock the system up. The other concern would be the order that the properties are initialized in and some tags not working because dependencies aren’t satisfied. I will attempt to look at the behavior at some point this week to see if I can add definitive behaviors.

1 Like