LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How can I Assert that an input enum contains a particular item?

Solved!
Go to solution

Since version 2018, LabView has had a palette of Malleable VIs that break unless a particular input type is attached.  For example, one will break unless the input is an integer; another will break unless the input is an array with a particular size.  These are particularly useful for building our own Malleable VIs that take different actions for different datatype inputs.

 

I would like an assertion that an input enum contains a particular item name.  This would guard against LabView "helpfully" updating the case structures in my Malleable VIs, which is a little mysterious as I ask here.  I can't use a case structure with the required item as a case, because LabView automatically updates the item name to match the input type.  I can't use an Equals node to compare the input enum with one with a desired type, because LabView automatically adds coercion dots to convert to a bare integer.

 

The closest I have found so far is this LAVA post by Kyle97330 / Autodefenestrator; it uses "Split Number" and "Format Into String" (with "%s" format) to Assert that the input is an enum... but I don't think this can extend to determine anything about the type of the enum.

0 Kudos
Message 1 of 18
(2,015 Views)

@DavidJSzwer wrote:

Since version 2018, LabView has had a palette of Malleable VIs that break unless a particular input type is attached.  For example, one will break unless the input is an integer; another will break unless the input is an array with a particular size.  These are particularly useful for building our own Malleable VIs that take different actions for different datatype inputs.

 

I would like an assertion that an input enum contains a particular item name.  This would guard against LabView "helpfully" updating the case structures in my Malleable VIs, which is a little mysterious as I ask here.  I can't use a case structure with the required item as a case, because LabView automatically updates the item name to match the input type.  I can't use an Equals node to compare the input enum with one with a desired type, because LabView automatically adds coercion dots to convert to a bare integer.

 

The closest I have found so far is this LAVA post by Kyle97330 / Autodefenestrator; it uses "Split Number" and "Format Into String" (with "%s" format) to Assert that the input is an enum... but I don't think this can extend to determine anything about the type of the enum.


Not sure how to do this either, except to follow the advice I gave in that other topic and make sure the malleable VI is loaded into memory so you can avoid the problems you are experiencing.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 18
(1,990 Views)

@billko wrote:
Not sure how to do this either, except to follow the advice I gave in that other topic and make sure the malleable VI is loaded into memory so you can avoid the problems you are experiencing.

Yes, that was very helpful advice in the non-malleable case - when manually updating a type def that gets used across a project.  This problem is slightly different - I want to create a Malleable VI that can be used in different sub-projects, with different enum types, and I want to prevent myself accidentally using it with an enum that it isn't compatible with.  I can write the requirement in the documentation, obviously, but it would be nice to have it enforced in the code too.

0 Kudos
Message 3 of 18
(1,983 Views)

@DavidJSzwer wrote:

@billko wrote:
Not sure how to do this either, except to follow the advice I gave in that other topic and make sure the malleable VI is loaded into memory so you can avoid the problems you are experiencing.

Yes, that was very helpful advice in the non-malleable case - when manually updating a type def that gets used across a project.  This problem is slightly different - I want to create a Malleable VI that can be used in different sub-projects, with different enum types, and I want to prevent myself accidentally using it with an enum that it isn't compatible with.  I can write the requirement in the documentation, obviously, but it would be nice to have it enforced in the code too.


Oh, I see what you are trying to do.  That does present a problem - one that I've had before as well - and I don't have an answer for that one, unfortunately.  Thanks for taking the patience to walk me through your problem.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 18
(1,968 Views)

There is an easy way to distinguish one enum from another.  On the Block Diagram, find the Variant sub-Palette and drop down the "Get Type Information" function.  Wire an Enum up to the "Variant" input, and when you run it, the name of the Enum will appear as a String on the "Name" output.  There's another output, "type definition", that is "True" if the Enum is defined by a TypeDef (which I strongly recommend).

 

Here is a LabVIEW 2019 Snippet (which won't quite work for you because you don't have the TypeDef "UI State" referenced in the first example) but which shows why using TypeDefs with Enums (particularly in your situation) is important.

Distinguishing Enums.pngDistinguishing Enums FP.png

The Snippet on the left yields the Front Panel on the right.  The first line shows an Enum "constant" that is connected to a TypeDef called UI State.  The Type Information Function returns the name of the TypeDef (UI State), and tells you that it is a Type Definition.  In particular, dropping another instance of this TypeDef, perhaps showing a different value for the Enum (such as "Exit UI"), should (and does) give the same name (because it is the name of the TypeDef, not the value of the constant).  In contrast, the next three Controls are associated with two other Enums -- the one named "Enum" (sorry, I should have named it "Enum 1") and "Enum 3" both have the values "One", "Two", "Three" -- in fact, Enum 3 is simply a dropped copy of Enum (1).  Enum 2 has a different underlying Enum (you can see the first value is "Zero"), but because "they are their own TypeDefs", the Type Information Function returns the name of the variable as the name for the Type Information Function -- it treats all three as different, even though two are copies of each other.

 

Bob Schor

0 Kudos
Message 5 of 18
(1,958 Views)

The only thing I can think of is an XNode.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 6 of 18
(1,954 Views)

@Bob_Schor wrote:

There is an easy way to distinguish one enum from another. ...


Thank you for reminding me about the variant tools.  Unfortunately, I think those are all run-time things.  I want the VI to be broken at compile time.

0 Kudos
Message 7 of 18
(1,929 Views)

@paul_cardinale wrote:

The only thing I can think of is an XNode.


Fascinating idea, thank you, but may be a bit beyond me at the moment!

0 Kudos
Message 8 of 18
(1,922 Views)

Doing this as a runtime check can be done pretty easily.  I could see a VI that returns an error output, or just a boolean telling you if an enum has some entries in it.  But I can't see a way that a VIM would be able to detect this at edit time.  You'll obviously need to run some code to perform the check, and XNodes are the only way I know to run code at edit time.

0 Kudos
Message 9 of 18
(1,889 Views)
Solution
Accepted by topic author DavidJSzwer

Here.  Made with LV 2019.  If you're using a later version, I recommend mass compiling it.

This is a very low risk XNode because it has no runtime functionality.

"If you weren't supposed to push it, it wouldn't be a button."
Message 10 of 18
(1,868 Views)