Better enum editor

[Intaris]

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.

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.

[JackDunaway]

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"

[tst]

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.

[Intaris]

Oh yes, add sparse enums and signed integers to the mix and the need for a better editor becomes even more urgent!

[Intaris]

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

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

[jmorris]

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

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

[Kevin_Price]

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

[JackDunaway]

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

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