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.
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"
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.
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. 😛
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...
>> 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.
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).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.