LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
mfitzsimons

Property Nodes Should use Enums

Status: Declined

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 Smiley Wink

 

propertyNodesEnums.PNG

Matthew Fitzsimons

Certified LabVIEW Architect
LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
15 Comments
JackDunaway
Trusted Enthusiast
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
Knight of NI

This would be beneficial for some property nodes, but definitely not all of them. After all, ActivePlot doesn't need to be an enum.

 

Also, the Disabled property has already been changed to an enum in LV 2009.

mfitzsimons
Active Participant

I haven't loaded up 2009 yet but will have a look.  This one has always bothered me and I have created my own custom control.

 

Matt

 

Message Edited by mfitzsimons on 08-19-2009 01:23 PM
Matthew Fitzsimons

Certified LabVIEW Architect
LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
JB
Trusted Enthusiast
Trusted Enthusiast

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+)

parthabe
Trusted Enthusiast

"In my opinion, the text should be shortened. (eg Enable, Disable and Disable+)"

 

 

 

Or even simpler like... Enb, Dis, DisG

Message Edited by parthabe on 08-20-2009 07:31 AM
- Partha ( CLD until Oct 2024 🙂 )
silmaril
Member

I don't like using an enum for this, because this gives me a coercion dot (which means an extra data copy if I understand this right).

Changing existent properties to enums would lead to coercion dots in existing code. That's also no good idea.

 

Especially for the "Disabled" property I like using a text ring, which I have in my user.lib (no type definition, because this would once again lead to a coercion dot).

 

It would be great if "create constant / control / indicator" would create such text rings. This would serve the purpos of having more readable code without introducing any additional type conversions.

 

If NI introduces any new properties, I'd strongly recommend thinking about enums (typedef, of course).

mfitzsimons
Active Participant

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.

 

disableHelpWrongLV2009.JPG 

Message Edited by mfitzsimons on 08-25-2009 11:52 AM
Message Edited by mfitzsimons on 08-25-2009 11:52 AM
Matthew Fitzsimons

Certified LabVIEW Architect
LabVIEW 6.1 ... 2013, LVOOP, GOOP, TestStand, DAQ, and Vison
StevenM
NI Employee (retired)

Nice catch, and thanks for the heads-up, mfitzsimons. This issue has been reported.

 

Steve M.

LabVIEW Documentation

AristosQueue (NI)
NI Employee (retired)

> I don't like using an enum for this, because this gives me a coercion dot (which means an extra data copy if I understand this right).

 

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.

rolfk
Knight of NI

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.

 

Rolf Kalbermatter

Rolf Kalbermatter
My Blog