LabVIEW
Large Enum list
Solved!
@mrbean wrote:
I have an enum that originally had about 30 items from which to select. Not too bad. The customer recently asked if we could add (seriously) over 700 entries to this same enum! These strings are all available in a text file, and are sequential (numeric value of each enum) in nature. Is there any way to read in, import, all of these values into the enum? Right now, my only option is to copy/paste each one manually.
It's a bit tricky. First, make a ring control. Use the text file to load those strings into the "strings" property node of the ring control. Replace the ring with an enum. There you go.
You can't (easily) do this with an enum, since enums strings can't be modified at runtime; however, if you have the enum control in a different VI and have a reference to it, you can update the property that way... but starting with a ring and replacing it is a lot easier.
Well, with some LabVIEW scripting you probably can create an enum control with all those items…
@GerdW wrote:
Well, with some LabVIEW scripting you probably can create an enum control with all those items…
You could, but as with anything if you want to edit a control, scripting or not, it can not be part of any running VI hierarchy. But then using directly the VI property "Strings[]" works too. Sure it could be considered scripting to use that property but technically it's part of the standard properties that are even available without the scripting extension being enabled.
But in the past I always used the import into Ring control method with changing it to a Enum afterwards.
Actually, I did use scripting to create an Enum. I was working on a data acquisition/control project that was driven by an Excel Worksheet that had (I'm guessing) about 150 row or column headers that became associated with the variable saved in that row/column. For example, one column was called "Trial Index", and when the Excel sheet was read, the data were put into an array indexed by the Enum. So if I wanted the "Trial Index", I just used the Enum as the index into the Array and got out the value (there's more to it than that, but that's the idea).
Data Structures are never "static", as we keep dreaming up new things to do, which we accomodate by "adding a few rows/column to the WorkSheet". Grumble, this means a new Version of the Code, with a new building of the Enum. I wrote a stand-alone program to do this -- it parses Excel, figures out all the Excel names I need, then using Scripting, builds an Enum with the names written into the Strings[] property. It seems to work ...
Bob Schor
I'm going to try to attach this as a Snippet. There are some sub-VIs that do "obvious things", but most of the code should be evident ...
I should mention that I've run this using LabVIEW 2012 and 2014 -- I'm hoping to migrate (and restructure) the code with LabVIEW 2016, but it hasn't happened yet.
@RavensFan wrote:
I created a sample enum that each item was 240 characters long with only the last character being different. It did not give me a problem.Icreated a sample enum, as soon as I went greter than 255 characters long, that is when it gold me there was a problem.
It seems like there could be a limit, but I haven't hit it yet.255 seems to be the limit.
That's per item name and that is because each item name is stored as a Pascal string. Pascal strings contain a single byte in the beginning that specifies the number of characters to follow and as such this can be maximally 255. Many things in LabVIEW are internally stored as Pascal strings such as the individual level elements of a path. There is another potential limit that all element names together can't be larger than 65535 bytes including the individual length bytes as that would overflow the internal typedescriptor of an enum.
In older LabVIEW versions that limit applied to the complete typedescriptor, which is why super-mega-prontosaurous clusters could turn LabVIEW into a mess, but that was changed in LabVIEW 8.0 by deprecating the old 16 bit typedescriptor format and instead using a new one that the Flatten to Variant returns. The Flatten to String by default lost the typedescriptor output that used to be the 16 bit typedescriptor.
@rolfk wrote:
@RavensFan wrote:
I created a sample enum that each item was 240 characters long with only the last character being different. It did not give me a problem.Icreated a sample enum, as soon as I went greter than 255 characters long, that is when it gold me there was a problem.
It seems like there could be a limit, but I haven't hit it yet.255 seems to be the limit.
That's per item name and that is because each item name is stored as a Pascal string. Pascal strings contain a single byte in the beginning that specifies the number of characters to follow and as such this can be maximally 255. Many things in LabVIEW are internally stored as Pascal strings such as the individual level elements of a path. There is another potential limit that all element names together can't be larger than 65535 bytes including the individual length bytes as that would overflow the internal typedescriptor of an enum.
In older LabVIEW versions that limit applied to the complete typedescriptor, which is why super-mega-prontosaurous clusters could turn LabVIEW into a mess, but that was changed in LabVIEW 8.0 by deprecating the old 16 bit typedescriptor format and instead using a new one that the Flatten to Variant returns. The Flatten to String by default lost the typedescriptor output that used to be the 16 bit typedescriptor.
I love this forum. 🙂
