From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Revisiting all of the existing Property Nodes and re-implementing them in a way such that a type-specific enum could be created from it, is a very long tail development task that will not be a focus in LabVIEW to change. LabVIEW NXG does not yet have an enum property types, it is something that is much more likely to be done in that environment.
All property nodes should use enums to make the code readable and not required to open help every time you need to set a properity. I find myself creating typeDefs for my self so I don't have to look up what the properity does and to make my code easier to edit. Example provided is to disable a control on the front panel. This is in the LabVIEW style guide
I completely agree with this principle. All PN's that ship with LabVIEW should have descriptive enums rather than cryptic codes. This is very much like the idea that PN's dealing with changing colors should have... lo and behold... a colorbox constant.
Message Edited by mechelecengr on 08-18-2009 06:35 PM
Obviously the readability is much better with enums. But this has a prize ! In LV2009, the "Disable And Grayed Out" enum uses about ten times more space on the diagram than a 2 constant.
In my opinion, the text should be shortened. (eg Enable, Disable and Disable+)
Found some badness in LV 2009's help. The help is wrong for the disable property (see image). Help list 0 as disable when it is actually the enable state. Agree, the text is verbose and should be as short as possible.
Message Edited by mfitzsimons on 08-25-2009 11:52 AM
Message Edited by mfitzsimons on 08-25-2009 11:52 AM
Not true. Coercion dots are used wherever there's a type change. Some of those type changes indicate a reallocation of data, such as from int8 to int16, but the coercion dot for the loss of a typedef is not a reallocation.
There is one issue Aristos has pointed out elsewhere about such enums. They will get localized with the LabVIEW language version you install. And if you happen to wire such an enum to a case structure the VI will break when being loaded in another language version of LabVIEW.
Revisiting all of the existing Property Nodes and re-implementing them in a way such that a type-specific enum could be created from it, is a very long tail development task that will not be a focus in LabVIEW to change. LabVIEW NXG does not yet have an enum property types, it is something that is much more likely to be done in that environment.