Globalization - UserDefaultCulture

We do not see the code that you use, but since you need to reset the original culture when finished, my guess is that you change the culture in the Control Panel. You should never do that. While your add-in is running, any other application started by the user will start with your culture instead of the culture that the user expect. And if your application crash, the user must manually reset it's original culture in the Control Panel. Many users do not know how to do that.

You should change the culture of your add-in instead.

I cannot be sure for an Excel Add-In, because I never use those (good old VBA is not dependant upon the version of Excel and is thus more convenient in my opinion), but for a Windows application, you can change the culture of the application with System.Globalization.CultureInfo.DefaultThreadCurrentCulture = New System.Globalization.CultureInfo("en-US"). It might also work with an add-in.

Since this has no impact on the Control Panel, you do no need to reset the culture afterward.

Hi James,
I do change the culture info by code. Looks like that

Private ReadOnly newCI As CultureInfo = New CultureInfo("en-US")
Thread.CurrentThread.CurrentCulture = newCI

This works fine. The question is how to set it back to the orignal value. Currently I am reading the registry

Friend Shared ReadOnly Property oldCI
        Get
            Try
                Using _
                    international As RegistryKey = Registry.CurrentUser.OpenSubKey("Control Panel\International", False)
                    Dim userDefaultCulture As String = international.GetValue("LocaleName").ToString()
                    _oldCI = New CultureInfo(userDefaultCulture)
                    Return _oldCI
                End Using
            Catch ex As Exception

                MessageBox.Show("Get oldCI failed. " & ex.Message)

            End Try
            Return Nothing
        End Get
    End Property

Select allOpen in new window

However on some clients computer I got a Null reference. So this approach is not very reliable and I'm looking for anther solution.

Regards,
Georg

Why would you want to change the culture in the CurrentThread, and then bring back the default culture? That means that the culture will change in the application while it is running, This could be very disconcerting for the user.

Hi James
please check

http://support.microsoft.com/kb/320369/en-us

<<You receive this error calling an Excel method when the following conditions are true: •The method requires an LCID (locale identifier).
•You run an English version of Excel. However, the regional settings for the computer are configured for a non-English language.
If the client computer runs the English version of Excel and the locale for the current user is configured for a language other than English, Excel will try to locate the language pack for the configured language. If the language pack is not found, the error is reported. >>

Hi All,
finally I found a solution in the msdn forum:
http://social.msdn.microsoft.com/Forums/en-US/327353dd-c153-4ce2-a265-4f70bdc2eb00/setting-datasetlocale-to-cultureinfoinvariant

The code looks now like this

Imports System.Threading
Imports System.Reflection

...
Dim CultureType As Type = GetType(Globalization.CultureInfo)
        Dim propci As PropertyInfo = CultureType.GetProperty("UserDefaultCulture", BindingFlags.GetProperty Or BindingFlags.NonPublic Or BindingFlags.[Static])
        Dim ciDefault As Globalization.CultureInfo = TryCast(propci.GetValue(Nothing, New Object(-1) {}), Globalization.CultureInfo)

Select allOpen in new window

Where ciDefault contains the User Default Culture Info.

Regards,
Georg

OK, I get it. I did not remember that problem. I got when the first version of .NET was still in beta, when we tried to get to an English version of Excel while the Control Panel was set to French. Since my customer was able to use the Multilingual User Interface Pack available, we installed that and it solved the problem.

Rereading the thread, I was drawn by the fact that reading the Locale info in the registry returned got you a Null. According to the documentation, you will receive a Null with OpenSubKey if the registry key does not exist. From there, I went on a little research and found out that a missing Control Panel\International entry is often missing in the registry.

I could not find the reason why, but I suspect the following. It would have to be tested, and since I do not have fresh installs of Windows in my environment, I cannot do it. If Windows is installed and no change is made to the Regional Settings, it is possible to assume that the International key is not created and that the system relies on the culture of the installed copy of Windows. I can this prove to be the case, when you would only have to get that culture when opening the SubKey gives you a Null, with system.Globalization.CultureInfo.InstalledUICulture.

I might have a Virtual PC with a default installation of Windows somewhere. I will try to find it and check.

Hi James,
you are right, Also the new solution reads the value from the registry. To use LCID instead of LocaleName is a valuable hint. Thanks for your input.

Kind regards,
Georg