by Michael S. Kaplan, published on 2005/08/16 17:45 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/08/16/452365.aspx
The title of this post seems like such an obvious point, but people have a tendency to mix them up. Now in fairness to these people, it is largely due to the integration that has been done to help them work together. Still, I am often left wondering how people trip over this fundamental issue. For example, this was something in my inbox recently:
Can you point me to a way of how to change user locale at run time using C#? I made few trials like:
Thread.CurrentThread.CurrentUICulture = new CultureInfo("de-DE") but it did not seem to work.
I needed this for automation purposes.
Now of course this code will not affect the user locale or the current culture (it will affect the "UICulture" which is to say the language in which the UI might be localized. But I honestly did not know if what was wanted here was fof unmanaged or managaed code. So I chose to answer for both:
If you want the managed thing, you want CurrentCulture, not CurrentUICulture.
If you want the unmanaged thingB, you want http://support.microsoft.com/?kbid=289125
But we were not out of the woods just yet -- since the association of the user locale being a part of the unmanaged world was not being made:
You are right. Actually, I tried both but user locale did not change. I checked the user locale in the regional settings of the control panel to see the change, but the user locale remain as is. Also, my Excel code did not have effect on locale sensitive areas like calendar and date format after executing the locale change code.
Here some of the other trials I made:
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR")
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR", true) also tried false
Thread.CurrentThread.CurrentCulture = new CultureInfo(LCID) where LCID is the hex value for a specific localeIn all of the above cases, there was no compiler error.
Ok, at least the problem is clear now -- they were clearly expecting that there was some managed technique that would change the user locale. However that is simply not the case. The various managed code snippets would simply work to change the current culture in the current thread in managed code.
It is true that the "default" setting of the current culture is based on the user locale. But that is one of those common sense integrations between the .Net Framework and Windows; any other default would be unlikely to be correct. This is not however a setting that goes both ways.
To help it be more confusing, you can contrast this with the InputLanguage class. The default is picked up is based on the default for new processes, and if you change the InputLanguage in the thread then that is the selection that will appear in the Windows Language Bar. So in that case, it does appear to go both ways.
In the end, it is hard to say whether a global strategy is being employed for such scenarios -- usually there is not. Each case is taken individually to try to do the right (whatever that means!), and occasionally people note consistency or the lack thereof with one item compared to another. In the specific situation of the keyboard, the Language Bar is representing the currently selected keyword in the thread, which is exactly what was set in the .Net Framework; in a situation like that having the.net framework affect the setting in Windows takes total sense. On the other hand, the user locale is a setting that affects every new process and thread that this user starts. Affecting such a setting based on the value in a property that is clearly meant to represent settings within a single thread would cause a lot more problems than it could ever solve.
Just always try to remember that the .NET Framework and Windows are not the same thing. They are good friends and colleagues who work together and who really try to make things work well, but not every single action that you can do in one can also be done in the other.
This post brought to you by "੫" (U+0a6b, a.k.a. GURMUKHI DIGIT FIVE)