Read/Write Enum to TDMS Property

[Hooovahh]

If you attempt to write an Enum to a TDMS Property the function will return error -68007.  "This channel or property value contains a data type that is not recognized by this version of LabVIEW."  Reading and writing Enums as Channel Data however works just fine.

There are a few work arounds for writing and reading TDMS properties as Enums, attached is one such example where we write the value as a string, then have to convert that back later.  There is extra work involved because we need to generate an error if the string value doesn't exist in the enumeration provided.

This idea is to ad native Enum Reading/Writing to TDMS properties.

[TiTou]

Why not going one step further and enable the read/write TDMS property to deal with clusters?

I once wrote a set of VIs inspired from OpenG read/write section cluster from the variant configuration file package : https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-TDMS-functions-robust/idc-p/1452834/highlight/tr...

[Hooovahh]

I thought NI adding enum support was a pretty low hanging fruit.  I mean numerics, and strings are supported.  Writing an enum as either and then doing the conversion to the specified data type wouldn't be too hard.  Heck even clusters can be done as a string.  Which got me thinking...so I created a couple VIMs that can get and set properties from the Enum or Cluster data type.  There are many ways to try to accomplish this and I admit mine might be flawed, but it is found here.

[nanocyte]

Kudoed because of the time savings and the removal of winks and nods but you can use the format into string and scan from string with enums.

[FixedWire]

It's a simple thing & easy enough to figure out but just had to go look this up. These things shouldn't be a rabbit hole.

[wiebe@CARYA]

But storing enums isn't simple.

If you store the string value, the storage becomes string sensitive. Fixing a typo will brake storage.

If you store the integer value, the storage becomes order sensitive. Inserting, deleting or reordering will brake storage.

You can store the string and the value, or even all strings and the integer.. Logic can then be used to retrieve the original value, but this logic will be application dependent, and never 100% safe.

Of course you can argue that any storage support is better then none, but I do think this is the reason it's not supported OoTB. It delays the problems to the user 🙄.

[Hooovahh]

Honestly I figure storing as only a string is good enough, and cover most of the use cases.  But if NI really wanted to take it a step further, they could store the type, and value, then use Variant to Data to convert it to the right type, passing through the errors as they come.  The down side with that is I bet it would be more strict, and would generate errors if enum values were moved around.  I think developers would rather the same string match even if it is at a different value.

Oh and as mentioned in a linked example, this code along with others, can be found in the Tremendous TDMS Toolkit found on VIPM.IO.

[FixedWire]

If it was cleanly done like Hoovahh does by securing read & write with a type def, it'd be OK. Wiebe is right & in retrospect find it a code smell. It's probably OK for the most part and will bite back when least expected. That's probably why I've not used it in all these years.

[nanocyte]

Fixing a typo in the enum should break the connection. This is common in many data storage formats like JSON or XML. If you need to fix a typo you should store a format version to the file. You have to keep around the old type defs (maybe in a PPL to provide namespacing) and apply them selectively based on the version. You then have to provide mutation code to "upgrade" the old enum to a new enum (or whatever, you could even change it to a boolean or a number at this point). A really good example of this system is xcontrols.