LabVIEW

[Darren]

Here's an obscure one for everybody.  The In Range and Coerce function (Functions > Programming > Comparison palette in 8.0 and later) takes many different datatypes as inputs.  One of the datatypes it accepts is a path.  Prior to LabVIEW 8.2, the In Range and Coerce function would always return False for its "In Range?" output if you wired paths as inputs, no matter what the values of the paths were.  In LabVIEW 8.2, however, the function can actually do something with paths.  Specifically, it will check the ASCII values of the path characters and indicate whether or not the input is within the specified range.  Check out this screenshot:

As you can see, the value of "c:\blah4.txt" is determined to be "in range", i.e. in between the values "c:\blah1.txt" and "c:\blah5.txt".  I don't know when I would possibly use this behavior, but it's nice to know it's there.

-D

P.S. - Check out past nuggets here.

Message Edited by Darren on 08-28-2006 10:40 AM

[Kevin_Price]

Also not sure if/when I'd use the behavior, but have not upgraded to 8.20 and am curious...

Does the "In Range?" operate like a pair of string comparisons?  In your example, would a path of "c:\blah314.txt" also be in range?

And for a more deeply-nested path, would it compare level-by-level, byte-by-byte, or only the final filename?

-Kevin P.

[Darren]

For the case of identical parent paths, it does act like a string comparison, so yes, "c:\blah314.txt" would be in the range of "c:\blah1.txt" to "c:\blah5.txt".

For a more deeply nested path, I believe it compares byte-by-byte.  So "c:\blah\heyyou.txt" would in the range of "c:\a.txt" and "c:\c.txt".

Hope this helps,
-D

[chilly charly]

---

Darren a écrit: ... Hope this helps,

---

Sure !.. need 1 g of acetylsalicilic acid now...

[Ray.R]

The more I learn, the less I know...  -sigh-

I never suspected that the range & coherce could (or would ever) work for paths.

Thanks Darren.

[HJPhilippi]

---

[...] As you can see, the value of "c:\blah4.txt" is determined to be "in range", i.e. in between the values "c:\blah1.txt" and "c:\blah5.txt".  I don't know when I would possibly use this behavior, but it's nice to know it's there.

---

I could imagine a scenario with VIs myVI_1.00.vi, myVI_1.01.vi, myVI_1.02.vi ... of different versions that are located in the same directory and wait to become loaded dynamically. Inside a possible caller, set the borders of the coerce function programmatically to the highest/lowest available VIs (assuming subsequent VI versions are all available) and the caller gets a VI loaded - whether requesting a VI name in range of the available VIs or a newer/older version that ist not there.

May sound a bit academic, but it can easily achieve some cool "injection" abilities of testing newer/older VIs without changing the caller's code, if this itself is prepared to handle dynamic VI calls! I know this could be achieved with other comparison functions, too - but one can say the same with the coerce function itself.

Greetings,
Hans

[Darren]

Good use case, Hans!  One of my colleagues was questioning the validity of my nugget because he didn't think there was any time we could actually use the functionality.  But this one makes perfect sense...

-D

[TCPlomp]

We use a timestamp as (part of) the filename, this coulde also be used as a filtering technique

Ton

[Ray.R]

ALL your nuggets are excellent and important Darren.

I'm sure we'll make use of them in ways that you'd never imagine.. 

[JeanPierre]

Is the comparison result dependant on the OS paths being case sensitive/insensitive?
In other words what is the result when x=C:\BLAH47.TXT on case insensitive paths on Windows?