Convert a typedef enum to a non-typedef enum?

[cober]

Is there a was to cast a enum that's connected to a typedef to a non typedef'd version?

I have a case structure (cases defined by enum typedef) which also includes a default case. In the default case I convert the enum to a string and parse the string for a special value. This together with the enum element's numerical value is kind of a fallback until a "real" case is defined for that element. Now the conversion and parsing could be used in another case structure I got. But to make it into a universal subVI the enum needs to be NOT typedef'd. Labview can't do automatic conversion here and a "type cast" loses the enum value completely. Is there any way to programatically remove the connection to the typedef from the enum before passing it to the subVI?

[johnsold]

I have read your post several times and am still not sure what you are trying to do.

I can typecast a typedefed enum to a non-typedefed enum. I can typecast the other way also.  If the enums have different numbers of elements, some values may not show up at the output.

How are you converting the enum to a string? And what are you trying to accomplish? Are you trying to identify that the enum has changed but the case structure has not?

Please post a VI showing what you have tried and what the problem is.

Lynn

[JÞB]

Disconnect fom type-def  or Deselect "Auto update" from type def

Either might do what you desire but,.... And here is the real question.  Why?  Really can you show a viable reason?  yes, there have been other discussions about removing those features (does anyone use them, especially deselectiong auto update from type def,? and if so why?)

I*d like to hear more.

[cober]

I would like everything within the case structure to be "universal" (i. e. independent of the "error" typedef). The typedef is part of an error handler. The reason is that until someone created/translated meaningfull error messages I'd like to automatically determine the values from the enum itself (the numbers between the angled brackets define the code, the string before that the preliminary message). While the structure is identical, I have serveral of the "error"-typedefs containing different sets of values. I'd like to use the same subVI for all of them instead of creating one for each typedef. The snippet you see already is specific for each typedef (although the structure again is identical for all) and I don't want to add another layer of specific subVIs.

The enum is converted into a string simply by "format into string". Nothing special there.

Casting the typedef'd enum into a non-typedef'd using "type cast" does not really work, because every time I change the typedef I also have to update the non-typedef enum that is connected to type cast. This means this wont work in the way I'd like it to:

So in principle what I need is the "disconnect from type def" just in a programmatic way.

[nathand · Accepted solution]

Make the input to your subVI be a variant. You can get the numeric value from it by converting to a numeric type; you can also get the list of corresponding strings by using GetNumericInfo found in vi.lib\utility\VariantDataType. Combining these should get you the information you want.

[JÞB]

Nathan has a good point but,  Why not use an error ring?  Yes the error ring is back and does what I believe you are trying to do.

[cober]

Yes, this does what I was looking for. Not quite happy with the "black box" vi (GetNumericInfo.vi) that's password protected, though. I like to know what's going on and who knows what happens with it in later versions of Labview. But as this is from NI I guess it's safe.

Now that I come to think of it, the question was a little bit off for what I need. I don't really need the whole enum to be made "typeless". A better question would have been: how do I get the numeric value and the string of the currently active element of an enum, no matter what type the enum is? Maybe something that could be called "enum to cluster" which gives me a cluster containing the numeric and string value of the currently selected enum value. Because in my case for the subVI I don't care what the other items of the enum are.

Seeing that I maybe just convert the enum to string and numeric value (as seen in the screenshot above) in the typedef'd enum specific VI and call the "universal" subVI with these two values. It's just one more function in the calling VI (although admittedly for ervy entry of the case structure) and much less additional code in the subVI ("and especially no black box").

[cober]

---

@JÞB wrote:

Nathan has a good point but,  Why not use an error ring?  Yes the error ring is back and does what I believe you are trying to do.

---

Wow, never heard of that (using Labview since 8.6). Unfortunately I'm currently stuck with Labview 2011. Looks like that's pretty much what my error handler comes to be, with my subVIs "converting" from my (developer friendly dropdown 😉 ) error list to to Labview error clusters.