Property Nodes Should use Enums

[mfitzsimons]

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

[JackDunaway]

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

[smercurio_fc]

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]

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

[JB]

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]

"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

[silmaril]

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]

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

[StevenM]

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

Steve M.

LabVIEW Documentation

[AristosQueue (NI)]

> 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]

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