LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to write a sub VI to accept two enums and decide if both of their strings are equal?

Kevin's solution certainly works. I used to do it this way as well until I encountered the solution Ben suggested above some time ago. Have a look at it, it's very elegant!
Message 11 of 15
(1,217 Views)
Here's a couple ways of doing it

Note all of these can run into race conditions since they use references.

The one with 4 inputs is safe as long as you never change the strings[] propertys on the enum controls. But you have to be careful that the control references you wire to it
are the same respective types as the ENUMs.

The other two could easily become race conditions if your not careful (I should have added dup references out, now that I think about it).

Matt W
0 Kudos
Message 12 of 15
(1,206 Views)

As dan_u said, Ben's posting is surely a much more elegant method!

D'oh!  I've used that method for string displays and file writes, but just didn't think of it for the string compare.  It's definitely better than the method in my earlier post.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 13 of 15
(1,201 Views)

Thanks again to everyone who responded with even more possible solutions to this issue.  It appears that you can't just wire in two different enums, no matter their dimension, just to check what their string values are (enums are strictly typed, and you have to have the same elements in the same order for enums to wire together).  The only way to do it with a sub VI is to pull a reference to the enum.  Is using a lot of references in a VI a performance hit?  I remember that being mentioned somewhere?  Also, as was mentioned by the poster (thanks Matt W), you have no control over when the references are read.

Can anyone help me out with what Matt W meant by adding "dup references out"?  Are you to check the output references, to make sure they are equal when they come out to what came in?  Is that a protection against the references changing during the sub VI's execution?  I am just wondering what added feature or protection this would provide.

I fear that the best way to approach the task is to write the same 3-function code (two "Format Into Strings" and one "Equals") every time the comparison is needed directly in the main VI (thanks Ben, I only wish this method could be used in a sub VI).

Again, I would really like to express my gratitude for all of the replies.  If I am wrong, and a better method exists from a speed of coding and VI performance point of view than using the same small chunk of code over and over again in the main VI, I'd really love to hear it.

Have a wonderful day!

0 Kudos
Message 14 of 15
(1,173 Views)
I meant that they should copy the reference inputs to some outputs so you can use flow control to serialize access to the properties. You'll notice that any of the built in VI's that use reference have a duplicate reference as an output.

For fun I wrote a VI that does what you want. But I'm not sure if it works in all cases, and if a labview update will break it. It's interesting but I wouldn't out it into production code. Someone else with more knowledge of labview might be able to make it into production quality, but it's rather hackish.
0 Kudos
Message 15 of 15
(1,151 Views)