by Michael S. Kaplan, published on 2005/10/18 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/18/482088.aspx
Yesterday when I talked about Comparing Unicode file names the right way, Mike Dunn asked the following question:
When using LCMapString to do the uppercasing, what's the right LCID to use? LOCALE_INVARIANT?
The CharUpperBuff docs say it "uses the language driver for the current language selected by the user at setup or by using Control Panel" which sounds to me like a language-sensitive operation that would have the same problems as using LCMAP_LINGUISTIC_CASING.
Yep, if you look at the various functions they all have text like that.
But I will tell you a secret -- that bit of text is utter nonsense, slated for removal in the updated versions of CharUpper, CharLower, CharUpperBuff, and CharLowerBuff (if you doubt me, you can look up early versions of the new text at CharUpper, CharLower, CharUpperBuff, and CharLowerBuff). :-)
I sort of explained it when I asked what linguistic casing means, but only in a very roundabout way. The thing is that unless you pass that LCMAP_LINGUISTIC_CASING flag, there is absolutely no locale-specific behavior whatsoever, irregardless of what LCID you pass.
(Well technically, we still do validate that the LCID is one we recognize, but we do not do anything with the locale; this would suggest that for performance reasons you should try to pass the LCID representing the default user locale so that you do not have load a new locale or anything.)
So, the answer to the question is that it does not matter what LCID you pass -- at all. But only if you do not pass LCMAP_LINGUISTIC_CASING.
Note: all of the above applies to unmanaged code only.
For managed code, the managed equivalent of LCMAP_LINGUISTIC_CASING in passed internally for every single culture except for the invariant one. So there you probably do want to use the InvariantCulture to do your casing when you are dealing with managed code.
This post brought to you by "ſ" (U+017f, LATIN SMALL LETTER LONG S)
# David on 18 Oct 2005 8:40 AM:
# Michael S. Kaplan on 18 Oct 2005 10:50 AM:
# Michael Dunn_ on 18 Oct 2005 12:28 PM:
# David on 18 Oct 2005 11:15 PM:
# Maurits [MSFT] on 19 Oct 2005 11:23 AM:
# Michael S. Kaplan on 19 Oct 2005 11:32 AM:
# Maurits [MSFT] on 19 Oct 2005 1:50 PM:
# Michael S. Kaplan on 19 Oct 2005 1:58 PM:
referenced by