Sorting it all Out Michael Kaplan's random stuff of dubious value Be sure to read the disclaimer here first!
Have you ever had two different people on your team where each of them came up with a cool feature idea, but the combination of the two ideas did not exactly work as well as it could have?
I suppose you can blame someone ine the group who is tasked with doing that wider review of features, looking for compat issues. Like a Technical Lead?
And that would be true even if it was actually the same person rather than two different people. Though in that case it should fall less on the Technical Lead and more on the person who came up with the two ideas.
Of course in this case the person who came up with the two ideas was me, the person who is also the technical lead. So I guess logic puts this one on me either way. :-)
Anyway, yesterday Aldo Donetti contacted me again with an interesting question. It went something like this:
Not sure why I thought Mongolian would be sortable in Vista...… and it’s not. (checked on CLR 2.0 and Vista RC1) Do you know if it should be? (together with Yi, Uyghur & Tibetan). CompareInfo.IsSortable returns false. Here it does not say that the method is CurrentCulture-sensitive. Am I missing something obvious? What cultures can I use for the comparison to work? Thanks again.
You know what? Aldo is right.
The first part of the problem is that CompareInfo.IsSortable (a method I added that I have mentioned before) is static, and uses the information in the sorting tables built into the .NET Framework itself.
Which is fine in and of itself.
But then you add in "Windows Only" Cultures, which I have talked about many times before. These helpful cultures are synthesized by .NET when the underlying platfom supports a locale that the .NET Framework does not understand.
And then you hit the second problem - if you are running on Vista than support for Mongolian, Yi, Uighur, and Tibetan was added via the "Windows Only" mechanism and you can create cultures for all of the following:
0x0850 mn-Mong-CN (Mongolian)0x0478 ii-CN (Yi)0x0480 ug-CN (Uighur)0x0451 bo-CN (Tibetan)
But it is getting sorting information from Windows, which the static CompareInfo.IsSortable does not know about. And thus the strings that have no weight as far as the .NET Framework knows will return false when this method is called.
Now the "fix" here is easy to contemplate (add an instance method as well which can then be based on the actual CompareInfo being used) and hard to implement in the next version of .NET a.k.a. Orcas (due to some interesting compatibility rules related to 'red bits' that folks over in DevDiv have set up that Soma and Jack and Jason and others have discussed which apparently apply to every freaking line of code we own).
But if course you can do it yourself, too (for now) -- you can p/invoke the Win32 NLS API function IsNLSDefinedString any time CultureInfo.CultureTypes includes CultureTypes.WindowsOnlyCultures. Which is almost the right logic.
And we'll get around to fixing it eventually, I suppose. :-)
Now in the meantime several other interesting issues also come out of things covered here, which I will be covering in upcoming posts (a good Aldo question can usually be converted into several interestingt blog posts!).
This post brought to you by ᠳ (U+1833, a.k.a.MONGOLIAN LETTER DA)
The question Richard Wilson asked me via the contact link: I am having problems with string comparisons
There is a powerful spam filter on http://blogs.msdn.com/ now. A very powerful one in fact. There really
Regular readers might recall a long ago blog entitled New in Vista: What's your name? Who's your daddy?
In the last couple of posts ( here and here ) I wrote some considerations related to the UI Language