I’m going through the IU videos now and noticed noticed there’s a “Motor_Template” view on one of the instructor’s projects. Anyone know if there’s a video covering how this is made?
I’m trying to figure out a way to pass an entire UDT to a view but can’t seem to find the specific video that explains this. I want the view to update its tag data when the UDT updates in the same way Vision does, that way I don’t have to reconfigure every view/container with this information.
You can pass in a parameter with the device’s tag path and then use that in your bindings in the View. I personally don’t like to use UDTType parameters anywhere, Vision or otherwise and always pass in the device tag path (or more specifically, the Device’s parent path and the Device name, to make up the Device tag prefix).
For example:
I used to pass parameters this way, but it is much quicker for us on the development side to pass the entire UDT. This way, instead of setting up a reference to every single tag (and subsequently having to add new tags and update every template/view), I can update the UDT, open the template/view, add a new label/input/whatever, and link it to a UDT property.
Doing it the way you described (or at least how I interpret what you described) requires me to then add a new parameter/property, link it up via expression, and go from there. It’s also heavy on the initial development side because I may need to add 10 or 20+ properties, link them all using the above method via expression, and so on.
Hence, I would prefer to pass the entire UDT into the view. If there is a way to utilize the Tag Path and subsequently pull the entire UDT into, say, an object-type parameter, then I’m down.
It doesn’t matter how you do it, for a View or Template, to use the new tags in a UDT, you’re going to have to bind the new tags regardless though? (ignoring edge cases using dynamic scripting)
In case it’s unclear, this is how I would bind for example a HOA tag to a label component’s text property in Vision: tag({Pump Template.DeviceTagPrefix} + '/HOA')
I deliberately went away from using UDTType parameters as I find them restrictive and clunky to bind with. Here are my reasons I don’t use them:
At a glance, it’s not possible to see by looking at a component’s properties which UDT instance has been bound to a UDT type property. E.g. in the screenshot from the Gold cert below, I have no idea which Tower UDT is bound, I have to click on it to find out. It’s also more difficult to change the UDT instance that it’s bound to.
It’s not possible to pass UDT instances in using a dataset to the template repeater/canvas. (This alone stops me from using them altogether).
In later versions, they’ve become less restrictive in terms of accepting other similar UDT types, but that was always a big turn off for me where if a template had a UDT type parameter assigned, it would accept that UDT type and that only.
You aren’t able to test with them within a template definition (that I know of), making it more difficult to test the development of a template. If using tagpaths, you can simply type your test device tag path into the field(s).
They can only be used with that specific UDT type hierarchy. Bindings via tag paths can pick up any tag type/folder structure that has the necessary items at the same relative paths. The target path doesn't actually have to be a UDT at all. (If UDTs could do multiple inheritance, the value of this particular point would decrease.)
UDT Bindings have historically had excruciatingly poor performance compared to indirect bindings.
I think this restriction has been removed in version 8 actually, however I would still never use these for all the other reasons. I had to endure looking at them when I did my certifications; that was enough for me!
