I have a template, it's bound to a UDT and using Drop Target method. It works as expected, I can drag a "motor" to the window and everything populates.
I would like to add a feature where I can open a popup window, to allow detailed setpoint manipulation. I can script the popup window on "mouse-clicked" event, but I am confused on how to make the popup work with my UDT.
In other words, I would like the popup to INHERIT the template's UDT path.
I want to build one template and have it pass to the popup the dynamic tag name, for instance. I do not wish to hard-code anything.
Make a script in the motor template to call the popup. Pass the path from the template to the popup.
FWIW, I've NEVER used the drop-target functionality. IMO it's better to have a single parameter to the template that is the UDT path and use indirect bindings in the template.
For any clickable template I always add a "clickable" parameter that enables/disables this functionality and uses the hand cursor instead of the mouse.
I re-watched the IA video on Parameterized Popup Windows a few times.
I noticed where the instructor gets "Tank" from the UDT browser/Tags folder. I am getting "Motor" from the UDT folder below it called "default". In fact, my UDT/Tag folder has a glaring error on it.
IA:
As noted above, dont pass UDTs to popups. Yes its in IAs tutorial, but its mostly inefficient and not best practice.
Instead, create custom property on your window...something to the effect of pathstr of type string. Then your mouse script will open the window and you will populate the pathstr string as a passed parameter, defined as the path to the root of your UDT.
On the window, just bind each widget as needed as an indirect of {1}/startpb, {1}/stoppb, {1}/amps, where {1} is the pathstr parameter.
If you do a search for "UDT Type parameters" and Vision, you'll see a large number of topics discussin the downfalls of them. I also would recommend never using them.
It's good marketing for Ignition as they sound great, until you use them, and you wish you didn't.
dropConfig in Perspective on the other hand, which is similar in concept to UDTType parameters in Vision, are perfectly fine to use when using the path option. I would never use the bind option for this though for similar reasons as vision
I did a test once in my early days of Ignition after reading about others saying to avoid it, and they're right. I had a screen with a dozen or so valves using the UDT drop method and decided to rebuild the screen using tag paths and indirect bindings instead. The drop method took a second or 2 to load the screen with live values, but the indirect bindings with tag paths loaded almost instantly. It makes a huge difference in responsiveness.
Think about it this way. If your UDT has even just 10 tags, and you're only using 3 for the template, if you have a screen with 10 of these templates on the screen, Ignition has to pull 100 tag values to load vs only 30. This is a small example. Many times your UDT will have 20-30 tags and you'll have 20 or more on the screen. If you use 20 for both that's 400 tags vs 60 tags if you're only using 3 tags in the template.
Make the change now before you get a lot more done and have to redo everything to improve performance.
I have tank UDTs some of which have 750 tags each, UDT Type parameters would obliterate performance, but it's also the limitations they cause for your template use cases
So, do I avoid UDT's entirely, or just avoid referencing them on-screen in a template or popup?
I ask this because it casts doubt whether or not to utilize UDT's at all.
I find the UDT structure very useful for organizing tags that contain history and alarming. I can copy a UDT for an analog signal, and make 5 different analog signal types, complete with all the parameters for alarming, history, etc. pre-filled. It makes organizing and deploying many tags intuitive to me.
My question now, is Abandon my UDT's? What would I do to replace them, create tag groups?
I feel like the UDT IS a tag grouping already.
On another note, if I put the UDT's into a tag group that is Leased/Driven, wouldn't that speed up the screens?
I am going to wait to do any more work on templates or popups today until I hear from the forum.
You should avoid UDT Type parameters, not avoid using UDT themselves. Just use a string parameter to reference the tag path and use indirect references.
I agree, use a single parameter named tagPath that way you can right-click a tag and just do a copy path then paste it in that parameter for easy tagging.
The issue for me with Tag and TagPath is terminology mismatch. A tag path in ignition is the full path to a tag. I actually do use two params, tagName and tagParentPath, or deviceName and deviceParentPath and I combine them in another custom prop tagPath or deviceTagPath (for UDT instances).
It is annoying because you always have to paste into both, but the benefit is that if you have a long tag path, you can actually see what device or tag it's pointing to at a glance, rather than having to click on the edit text icon, and I feel that's more important than slightly faster dev
Again, this is why I do not use UDTs as parameters but rather the path to the UDT instance. It helps with consistency between all templates, popups, and template popups. It's also much more efficient and there's no extra steps to get the path from the UDT instance or create an extra parameter.
As far as exactly what parameter(s) you want to use for the path or to create the path there are many ways to skin that cat.
