UDT Parameters vs UDT Custom Properties

I’m trying to determine why I would use UDT Parameters vs UDT Custom Properties. I think I have seen @pturmel mention that he prefers the use of custom properties in his projects, but I’m not sure why?

It appears to me that the main distinction between UDT Parameters and UDT Custom Properties is that the Parameters can be bound to by the UDT child elements within the scope of the UDT.
However, within the scope Ignition Project, it appears that bindings can be made as easily to Parameters as they can be to Custom Properties. Is there a performance difference or other distinction that I am missing?

I think I have seen people use the terms “parameters” and “properties” interchangeably/incorrectly throughout this forum. So for the sake of clarity:

These are UDT Parameters

These are UDT Custom Properties
image

1 Like

I don’t recommend UDT custom properties. I recommend direct or indirect bindings to the tag values and tag parameter values you need. Templates and re-usable windows should use indirect bindings, where a tagpath or partial tagpath is a string parameter of the template or window.

1 Like

I agree there is confusion betweeen parameters and properties :sweat_smile:
I think people are excused because Ignition contributes to this confusion:
image

-That beeing said, I find myself using UDT parameters for rescources needed in the UDT scope, like binding expressions
-Other rescources I typically place in memory tags
-Actually I sometimes make memory tags that refere to relevant parameters -to more easily browse these resources later on :face_with_raised_eyebrow:

How would custom property of a UDT behave compared to a fullblown memory-tag. hmm. :thinking:

1 Like

Hi, @pturmel. ref: Parameterized Popup Window and UDTs - Popup Windows - Is “Indirect binding” preferable to binding a complete udt? We currently are using udt-type parameters a lot and love how drag-and-drop of template instances is verry efficient.

Yes. IMNSHO. Backed by many reports of performance problems with binding whole UDTs.

Give up the drag and drop.

1 Like

I ran into performance issues as Phil noted. Drag and drop is nice, but it’s also nicer to be able to change multiple instance paths at once, something you can’t do with UDT custom property, it’s one at a time.

1 Like

Hey, how this can be done in the perspective?

found the answer here
UDTs and Template Views Video at Inductive University