Creating sparse enums in CVI for LabVIEW

[GuenterMueller]

Hi tst.

I also get rings instead of enums.
Confusing: The NI document introduces this method as a way to create sparse enums but in (14) it says: "On the front panel of this VI, the custom text ring control appears." This is what I get, too.

Then I checked the .fp and the rings had the data type "int". In LabVIEW, enums must be U8, U16 or U32 -> So I changed the data types in the .fp (see attachment) and again imported the .fp in LV7.1.1 -> no change, again I see the rings (but this time with unsigned data types).

Who knows, how to get the sparse enums in LabVIEW ???

Regards, Guenter

[tst]

Yes, those are still rings.

The article definitely speaks about sparse enums and people also talked specifically about sparse enums, but I suppose it is possible that it refers only to sparse rings, which were unavailable before LV 7.0. I'm actually downloading CVI to see if I can play with it.

[jr_2005]

Careful! Once you start to use CVI you might just find that you like it!

JR

[Ben M]

Hello tst,

Unfortunately, you are correct.  If I understand you correctly you are trying to create a way to pass a tuple (string,integer) the same way that the enum does.  The enum is built on an array and just uses the array index as the integer when it passes the value.  This is why you cannot create a sparse enum.  I don't believe that there is currently a way to duplicate this behaviour using CVI widgets.

[tst]

---

@Ben M wrote:

The enum is built on an array and just uses the array index as the integer when it passes the value.

---

At face value, I would agree, but I did manage to create an enum which is out of order fairly easily, without even using any supersecret scripting (see attached, LV 7.0), and that document and other people also clearly refered to sparse enums, which is why I'm still hoping this could work. Do you know this for a fact or are you just quoting some internal KB \ something you heard? (no offense, but not all of NI's AEs are created equal. I ran into more than one who were not always that helpful to the users in the forums).

BTW, the attached also demonstrates quite clearly that the value of the elements is not defined in the type descriptor, which means it must be somewhere else, but looking at the binary structure of that control didn't reveal anything conclusive either. 

[tst]

Actually, after trying it again just now, it seems that this reordering does not propogate and just stays in the control (makes sense, since it's not in the type descriptor). You can see this by probing the enum wire. The string displayed is the string which is found in index n of the string array, where n is the numeric value of the wire, so if you select "Three", the probe shows you 3 and "One", which is the fourth element in the string array.

[tst]

---

@jr_2005 wrote:

Careful! Once you start to use CVI you might just find that you like it!

---

Not really.

I won't say I went through tutorials and really tried to learn it, but I wasn't that impressed. I think it looks (I'll be gentle) not very nice and I miss the ease of use of LV. For some reason, it does not seem to me to be very polished.

By the way, this has nothing to do with C vs. LV. I think Visual Studio and Eclipse, to name a couple of IDEs, look great. Why do people choose CVI over any other C compiler? Does it have any particular advantages?

Anyway, Rolf said that what he saw in the past was most likely sparse rings and not sparse enums, and that seems reasonable when you consider the way the enum datatype is represented in LV, so I think we can officially say that there is currently no way to have sparse enums in LV.