Coerce to Type: Ctl Disabled enum to Page Enabled enum

[paul_cardinale]

Ugh!

When converting an enum for a control's Disabled property to an enum for a tab page's Page Enabled State, you have to send it around the mulberry bush (WHY?).

[BertMcMahan]

There is no possible way for LabVIEW to understand automatically how to convert between two different Enum values. An Enum is a user-enumerated list of values.

For example, what would the expected behavior be for converting a control's Disabled property to a "Day of the Week" enum? Even "similar" enums should not be naively converted, for reasons listed below.

The second thing you're doing is a very dangerous one. It works be cause Enums are stored on disk as integers, and you can convert an Enum to a U32. For example, if your Enum items are [Sunday, Monday, Tuesday, etc] then Monday would be stored simply as a 1 on disk. You can convert that to a U32 representing a 1.

Converting a U32 to an Enum works the same way- a U32 value of 2 would convert to an enum (mentioned above) as Tuesday. If you converted that to a "Page Disabled" enum, it would convert to "Disabled and Grayed Out".

Your system works because there is no direct route between Enums and Enums, but there IS a route from Enums to U32, but it is *very* risky to use this behavior. It works in this case, but imagine the following scenario:

You have two user defined Enums. The first is "Coffee Pot Power" and is defined as [On, Off]. The second is "Coffee Pot Heater" and is defined as [Off, On]. Both of these are valid Enum declarations. If you wanted to say "If the Coffee Pot Power is Off, turn off the Heater." then you COULD do a "naive" Enum conversion of Coffee Pot Power -> U32 -> Coffee Pot Heater, but you'd get "Off" -> 1 (since it's the second item in the first list) -> On (since On is the second one in the second list).

Your specific example works because those two enums have very similar values and are presented in the same order. Unfortunately this code works "accidentally" and is a bad practice to get into. A Case structure would be a MUCH safer way to accomplish the conversion you're looking for.

As an exercise for the reader... what would happen if, in a future version, NI decided to add an "Enabled and Glowing" state to the control's Disabled property? What would happen to your code? What would you WANT to happen to your code?

[paul_cardinale]

Well it pretty much goes without saying that things like coercion and typecasting should only be done with caution; making sure that what you're doing really makes sense.

My code doesn't work "accidentally"; I made sure that what I coded would produce the desired result.  If the enum values of the different types had not represented equivalent states, I would have coded it differently.  Also, I would never try "converting a control's Disabled property to a 'Day of the Week' enum" (who would?).

[BertMcMahan]

Perhaps I should rephrase, sorry, I didn't mean any insult. When I said "accidentally" I meant that those two particular enums are probably ordered that way coincidentally. I doubt (but cannot prove, of course) that no one intended them to be cast like that, hence it's something of a "happy accident" that your shortcut works. Apologies for any offense 🙂

And my day of the week example was meant to illustrate the general incompatibility between nearly all enums- I was asking more "what is the expected behavior of an enum-enum type coercion algorithm".

The Help for "Coerce to Type" says that it is intended to safely coerce a type without misinterpreting data. It begins by coercing the input to the output. There is no way to safely and automatically coerce two different enums.

You CAN coerce the integer representations of enums, however, which is why your second approach works, but you have to first explicitly tell LabVIEW to "Treat this enum like an integer, not as an enum".