LabVIEW Idea Exchange

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

Better enum editor

Status: Completed
Available in LabVIEW 2012

In line with giving us a better polymorphic VI editor, doing the same for Enums would be great.  The current implementation is SSSLLLOOOWWW and unwieldy.

 

Enum editor.PNG

 

Please re-visit this functionality to make our lives easier....  So many people create enums via rings for exactly this reason.  This is just unneccessary.

17 Comments
JackDunaway
Trusted Enthusiast

I would like to see features availabled in the MCL, such as drag/drop, selecting multiple items at once to move or delete... Kudos. Oh, and of course, the new enum editor needs the checkbox for "Sequential Items" Smiley Wink

tst
Knight of NI Knight of NI
Knight of NI
Personally, I almost always add items to an enum by using Shift+Enter while editing the text in the control itself. This adds a new element to the enum while you edit it and is much faster.

___________________
Try to take over the world!
Intaris
Proven Zealot
Oh yes, add sparse enums and signed integers to the mix and the need for a better editor becomes even more urgent!
Intaris
Proven Zealot

@tst

I do that too, but it's a bit of a pain if you happen to press enter instead of shift-enter half way down an enum with dozens of entries.

 

Even though this is a good way of doing things, I think we need more than just that.  Especially if we get sparse enums, this shift-enter method kind of fails to keep up with the assignment of values to the enum.

JackDunaway
Trusted Enthusiast
Shane mentioned the signed integers suggestion, that is here: Enum Datatypes. (In that link, try to ignore the noise I created by talking about coercion, and just focus on supporting signed enums in LabVIEW. There are many more clever uses of signed, sparse enums than simply trying to avoid a scalar coercion. Smiley Wink )
jmorris
Active Participant

Another major reason to improve this interface is that it is highly encouraged by NI to use for typedef states for state machines.  Using typedefed enums works great!  Editing them is slow and painful, as stated above.

 

Like tst I also use the Insert Before and After contextual commands on the control to avoid this window right now since it is so slow to bring up, but eventually you have to edit the name of a current state or go in for some other reason.  😛

Jarrod_S.
Active Participant
Extremely wonderful idea! It is almost unusable. My big gripe is that you can hit Enter to go to the next item line to start typing UNTIL you get to the bottom of the listbox. At that point hitting Enter causes some chain of events that loses Key Focus in the listbox. So you get a whole 7 lines of keyboard navigation, then you're off to the mouse the rest of the way...
Jarrod S.
National Instruments
Kevin_Price
Proven Zealot

Here's a little side-door I've used when circumstances warrant.  If I have or can readily produce an ascii file full of the strings I want in the enum (in order of course), I'll assign them to the "Strings[]" property of a ring control, then after execution ends, I right click the ring and "Replace..." with an enum.  The strings remain intact...

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
JackDunaway
Trusted Enthusiast

>> I'll assign them to the "Strings[]" property of a ring control, then after execution ends, I right click the ring and "Replace..." with an enum.

 

Our group used the same method for a while, but an insidious bug attacked at least half a dozen times - forgetting to change the Ring back to an Enum! Dynamically launching this VI was the key to editing enums directly given an array of strings, and we havn't screwed up the process of mass-updating an Enum Typedef since.

Neil.Pate
Active Participant

I know the editor seems much improved in 2011, but here is another suggestion.

 

Please can the items list be made bigger! There is plenty of white space in that tab page that could be put to better use by displaying more items.

 

Even better, unlock these VIs for us to tinker with ourselves (I recall an update to 8.6 that fixed a big in one of the numeric range fields, the patch was just a replacement for one of the internal vi.lib VIs if memory serves me correctly, so they are there to be edited).