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):

 

[tst]

Also, here's a somewhat related idea - String case structures should default to being case insensitive

And, expanding on that idea - if this idea is accepted, wiring a string to the primitive should probably make it default to being case insensitive.

Message Edited by tst on 30.04.2010 01:53 PM

[Intaris]

I like this idea of having the option for case insensitive, but I really dislike the option of insensitive compare by default. 

[Jim_Kring]

Another question: how would you change the icon, to signify that it is a case insensitive comparison?

I came up with this, but it's not great (too big):

 

[rolfk]

Why would you need the Aa twice in that icon. Just put an A and a above each other. Might still be sort of large compared to the = operator now but at least not as huge.

[Manzolli]

Definitely we need to know that the comparison mode changed.

[Darren]

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?

-D

[muks]

NIce idea. Another one that we have accepted to to with. But as intiaris suggested the case sensitve comparing has to be the default feature.

[Manzolli]

Better keep the same size as the other comparison functions. Maybe a darker pink. Now Kudos!!!

[Ray.R]

This feature would certainly simplify code..

[Darin.K]

I wholeheartedly agree that this is a common use case and worthy of a clean solution.  Virtual Kudos for the salesmanship, using the Icon view and what appears to be the handywork of the Block Diagram Cleanup makes it look unwieldy.  However, I find a more compact arrangement to be clean and self-documenting.  Most importantly, it doesn't mess with the notion of equality.  Equality has a very precise definition and I am not a huge fan of altering it.   To me, this sounds more like a job for a refined string matching function like my old friend Match Regular Expression.   I would rather add a function to match entire strings (like adding the ^ and $ qualifiers) and replace the offset output with a boolean to indicate the match.   There can be a boolean input for case insensitive matching (like Match Regex) which can default to case insensitivity since case sensitive matches would likely use Equals.

If this idea is implemented, how would save for previous versions work?  Would this break VIs, or would this mode be stripped like output configurations and leave VIs which work, only not as expected?  Is LV clever enough to replace this "Equals" with the equivalent primitives?

If I did this a lot I would add a subVI to my palettes which dropped the equals and two To Lower Case functions, or add a RCF plugin.