All enums for built-in LabVIEW property and invoke nodes, functions, and VIs should be type definitions

[RyanWright]

I make a lot of VIs that use built-in LabVIEW property and invoke nodes, functions, and VIs that have enums for inputs.  I have noticed that on most of them, the enums are not type definitions, as shown in the picture below.

These enums should really be type definitions so that if their values (types) ever change, I don't have to manually recreate all of my front panel controls and indicators as well as block diagram constants in my VIs that use the built-in LabVIEW code.  This suggestion really applies to more then just enums.  It should really apply to any type that isn't an elementary type such as a container, a ring, etc.

Implementing this suggestion might also help new LabVIEW developers to learn about and use type definitions in their code.

[AristosQueue (NI)]

You don't have to worry about this.

a) If the enum is only used as an input to the method or as a write for a property, R&D is only going to add to the end of the enum. Your code may continue to use the old enum without modification. 

b) If the enum is used as an output, these enums will not change. The LV R&D policy for the last couple years and into the future on such nodes is to deprecate the existing property/method and introduce a new one with a different enum to avoid breaking your code that may be testing all the cases.

New properties and methods are using typedefs for enums, but we are not going to retrofit all of the existing ones.

[RyanWright]

OK.  Thank you for the response.

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/All-enums-for-built-in-LabVIEW-property-and-invoke-nod...