Lower

[shapper]

Hello,

I am comparing two strings in a LINQ query as follows:

where t.Name.StartsWith(q)

I want to select the record even if t.Name is "New York" and q is
"new" ... I don't want case to affect it.

I changed it to:

where t.Name.StartsWith(q.ToLower)

But I don't know how to do this to t.Name ...

Thank You,
Miguel

 

[Arne Vajhøj]

I am comparing two strings in a LINQ query as follows:

where t.Name.StartsWith(q)

I want to select the record even if t.Name is "New York" and q is
"new" ... I don't want case to affect it.

I changed it to:

where t.Name.StartsWith(q.ToLower)

But I don't know how to do this to t.Name ...

If t.Name is a String I would assume you could use
ToLower there as well.

Arne

 

[Pavel Minaev]

Hello,

I am comparing two strings in a LINQ query as follows:

where t.Name.StartsWith(q)

I want to select the record even if t.Name is "New York" and q is
"new" ... I don't want case to affect it.

I changed it to:

where t.Name.StartsWith(q.ToLower)

But I don't know how to do this to t.Name ...

Never, ever, use ToLower/ToUpper for case-insensitive comparison. It
just doesn't work for some languages. Instead, use the appropriate
overload:

t.Name.StartsWith(q, StringComparison.CurrentCultureIgnoreCase)

Note the "CurrentCultureIgnoreCase" bit - this is the same behavior as
StartsWith with only 1 argument, but also ignores case. If you do
_not_ want to use culture-based comparison (e.g. if you're comparing
identifiers rather than user-produced text), you might want to
consider InvariantCultureIgnoreCase, or even OrdinalIgnoreCase.

 

[shapper]

Never, ever, use ToLower/ToUpper for case-insensitive comparison. It
just doesn't work for some languages. Instead, use the appropriate
overload:

t.Name.StartsWith(q, StringComparison.CurrentCultureIgnoreCase)

Note the "CurrentCultureIgnoreCase" bit - this is the same behavior as
StartsWith with only 1 argument, but also ignores case. If you do
_not_ want to use culture-based comparison (e.g. if you're comparing
identifiers rather than user-produced text), you might want to
consider InvariantCultureIgnoreCase, or even OrdinalIgnoreCase.

Hi,

I am just a little bit confused between:
InvariantCultureIgnoreCase and CurrentCultureIgnoreCase

In this case I am using this in an AutoComplete.
So when a user writes "Ne", which is the value of q, then my Linq will
look for all records where Name starts with "Ne", "ne", "nE", ...

Which one should I use in this case? InvariantCultureIgnoreCase or
CurrentCultureIgnoreCase?

Thanks,
Miguel

 

[Pavel Minaev]

I am just a little bit confused between:
InvariantCultureIgnoreCase and CurrentCultureIgnoreCase

In this case I am using this in an AutoComplete.
So when a user writes "Ne", which is the value of q, then my Linq will
look for all records where Name starts with "Ne", "ne", "nE", ...

Which one should I use in this case? InvariantCultureIgnoreCase or
CurrentCultureIgnoreCase?

For people's names, CurrentCulture is definitely the best, since it's
comparison of strings in natural language, and it is directly visible
to the end user.

 

[Ciaran O''Donnell]

Hey there, the comments about using a
StringComparison.CurrentCultureIgnoreCase are all correct. But if you
actually are going to to user ToLower on 2 strings to compare them, I
remember thinking that it is better in .NET to compare two uppercase strings.
Apparently there is some optimization of the framework for that. I think its
mentioned in "CLR via C#" (which is the second version of "Applied .NET
Framework Programming".

 

[Pavel Minaev]

Never, ever, use ToLower/ToUpper for case-insensitive comparison. It
just doesn't work for some languages. Instead, use the appropriate
overload:

I thought this was a strong enough statement that it warrants some
clarification, so here are the references:

http://blogs.msdn.com/michkap/archive/2006/03/15/551773.aspx
http://blogs.msdn.com/michkap/archive/2006/01/11/511557.aspx

And in general, I'd heartily recommend reading a couple of posts
Michael's blog to anyone who deals with Unicode (which is pretty much
every programmer out there, these days) to better understand the
issues involved.