by Michael S. Kaplan, published on 2005/10/27 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/27/485462.aspx
If you go back to March of this year, I post about how the WinForms DateTimePicker and MonthCalendar do not support culture settings. But if you look at the text, you will see how I had my 'NLS eyes' on, thinking about CultureInfo.CurrentCulture and how different calendars were not supported there.
Putting on my 'GIFT eyes' though, there is a wider issue, and that is the fact that the localized text in all of the Windows Shell's Common Dialogs picks the localization based on the UI language of Windows, rather than the .NET Framework's CultureInfo.CurrentUICulture.
Now this would obviously be the case when you do not have the language resources available -- after all (for example), the Russian version of Windows cannot spontaneously create French resources for the FontDialog class just because you write code to set the Thread.CurrentUICulture property to be new CultureInfo("fr-FR"). And that is because the underlying Font Dialog Box in the Shell loads its resources based on the UI language in Windows.
But the same problem is true if you have the Windows MUI language pack for the appropriate language installed; the common dialogs are still loaded according to the Windows UI language, not the CurrentUICulture that you might have set in .NET.
Of course it is terribly frustrating that the resources might be there yet they still might not be used. But there is no function to change the UI language without logging off, and of course it is not very likely that a managed application running in the context if the desktop can survive past a logoff/logon....
The ironic1 part is that the Windows common controls do have a workaround for this issue, even though there do not seem to be many areas of localized text in them. If you look at the topic entitled Localization Support for the Common Controls, it talks about the InitMUILanguage function (which initializes the UI language for the common controls within a process) and the GetMUILanguage function (which retrieves the UI language for the common controls within a process, or the user UI language if it has not been set). In theory there is no reason why you could not call this function at any point, but in practice it is unclear from the documentation if it will work when set multiple times (hell, I am still having trouble picturing when it works at all, since I cannot think of any localized text!).
But in any case, for the time being it looks like the CurrentUICulture and Thread.CurrentUICulture cannot be used to affect the Windows Shell's Common Dialogs that are wrapped by Windows Forms in the .NET Framework. If you want to support this, you will need to wrap the Shell functions in comdlg32.dll and then use the HOOKPROC to do a bunch of owner draw work and/or custom template loading to get this done. Which is a bit much for any project....
1 - When I say ironic here, I mean it in the Alanis sense. You know, like rain on your wedding day. In other words, when I say IRONIC what I mean is UNFORTUNATE.
This post brought to you by "ǻ" (U+01fb, a.k.a. LATIN SMALL LETTER A WITH RING ABOVE AND ACUTE)
Xie on 13 Nov 2009 12:41 AM:
Is the method InitMUILanguage() can work?
referenced by