Type descriptor constrain when flattening a variant

[antant+]

The background:

I use a cluster to store settings. This cluster contains many items including a large enum (3000 items)   in multiple positions (inside clusters, arrays of clusters..).

The "data string" which results from "variant to flatten string" is propagated to client software via TCP. On client side, settings are reconstructed using the same type definition.

I recently added some items in the enum and the "LabVIEW: An input parameter is invalid..." message appeared.

The problem:

After removing some items from the enum, I identified that the value of the first word  of the "type string" was close to "FFFF". This correspond to  the number of elemental type descriptors contained in the type descriptor.  By adding more items, this would overflow.

Please see below and attached a reproduction of the problem:

To solve this, I replaced the enum with a ring just to take a valid type descriptor, but this is a clumpy way (overriding type definitions)

Is anyone aware of an elegant work around?

Thank you. 

[antant+]

Tried again to attach the vi where the problem is reproduced, but without success!

[paul_cardinale]

It should be against the law to have an enum with 3000 items.

[cbutcher]

---

@paul_cardinale wrote:

It should be against the law to have an enum with 3000 items.

---

If you weren't supposed to have an enum with 3000 items, it wouldn't be a possibility?

Just kidding. Dear OP, please consider if you can reduce the size of your data types. Do you really need so many? Perhaps you have lots of different things grouped together that could be separated? It looks a lot like a very long integer as a string, followed by some descriptor? (I didn't check all 3000 though 😉  )

Maybe a number and an enum could be combined to reduce the size?

[natasftw]

---

@antant+ wrote:

The background:

I use a cluster to store settings. This cluster contains many items including a large enum (3000 items)   in multiple positions (inside clusters, arrays of clusters..).

To solve this, I replaced the enum with a ring just to take a valid type descriptor, but this is a clumpy way (overriding type definitions)

---

Doesn't this seem to be competing ideas?  "I don't want inelegant things on my block diagram where I work with the code."  "I don't mind inelegant things on the FP where my users will spend their time in the program"

That aside, is there a reason you're needing to convert both to variant and then string?  This seems like duplicated work unless you're doing something with the variants elsewhere in the application and you've pared that out just for this example.