Case Insensitive Comparison Mode for String Equality Comparison

[Jim_Kring]

I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:

 

It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):

 

[CrystalTech]

The = sign could be changed to a squigley equal sign which means almost equal to.  Then you would not have to change the color.  49 Kudos already!  This need to be implemented, despite some concerns.  WE LIKE IT!!

[James@Home]

I like the idea, it would be a nice addition to the vi.lib. Until then, I have a sub-VI in my user library for this function. My Icon has the equal sign pink with the lower bar half as thick.

[RWR]

This capability would be most welcome.

[AristosQueue (NI)]

---

@Darren Nattinger wrote:

Maybe just make the equals pink to indicate it's operating in a special mode for strings?  Perhaps we could expand this idea later for other special modes of equals, like make the symbol orange if we're doing an "approximately equal" for SGL/DBL values?

---

A color change cannot be the only indication. I'm working with too many color blind people lately and have learned my lesson thoroughly. Make a glyph change of some sort. I like CrystalTech's suggestion of the "approximately equals" sign (the two wavy lines instead of straight lines of the normal equals sign). I'd also be ok if it was a plain equals but with "Aa" written on it, sort of merging the two existing primitive glyphs.

[DAD]

An interesting idea.  But I've got to ask: couldn't you just create a subVI that is what you show and use it?  Is there an appreciable execution difference between a native node and calling a subVI?  (And if you want to be able to select the case sensitivity set it up as a polymorphic subVI.)

[AristosQueue (NI)]

DAD:

> couldn't you just create a subVI that is what you show and use it?

Yes, that is definitely possible. The issue is that, in my experience, users generally feel comfortable with dropping a generic primitive (in this case, the Equals primitive, which is fully polymorphic to accept any LV data type) and then tuning it to the particular type of operation (for example, the existing "Compare Aggregates" vs "Compare Elements" options). Making the special case into a separate node is often not as easy to use. In this case, adding another item in the comparison palettes that is not as universal but is sort of like equals would clutter the Comparison palette. Moving the case insensitive equals over to the Strings palette would probably not be findable by many users.

[EricC.]

Very good idea !

I have see in another compiler a very usfull comparaison function

a "tolerant comparaison".

This function is case insensitive AND ignore all accents.

I'am French and in frenche, the "é", "è", "ç", "ê" ...etc are offsent present in text.

[Manzolli]

Same here in Brazil, as the French language, Portuguese has "ç", "õ", "ü", "à", "í", "ê", etc. An option (a new function or an option to an existing one) to treat, for instance, "a" equal to "à", "á", "â" and "ã" would be nice.

[Kosta]

Related topics: 

"Case insensitive match" option of Case Structures with string selectors is not visible on the block diagram.  I would appreciate consistent indication of upper/lower case sensitivity between case structures and comparison functions.

I'd like to be able to multi-select several equal nodes and set case sensitivity on the lot of them at once.

I would appreciate case insensitive option on other applicable comparison functions.

[Jason_Harrigan]

Good idea, the approximately equal sign should be used.