You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a desktop application that reads and writes numerous ini files that contain dates and numbers in UK format (en-GB). If we run the application on (say) a French PC then IConfig.GetDouble() throws a FormatException because it can't parse values in the file such as "1.23" (because the French use "," as the decimal point character). The nature of the app means we can only supply these ini files in UK format, and can't (for example) provide French customers with ini files that have been formatted to their locale.
As a workaround, I have found that I if I set the CurrentCulture to "en-GB" just before instantiating the IniConfigSource object, then back to the PC's region (e.g. French) right after creation, then I am able to read and write the file regardless of what the CurrentCulture is. I'm not sure how this is possible, but am assuming IniConfigSource stores the culture at the moment of its creation, then uses this during all read and write operations?
I was wondering if there is a more elegant solution to the above? It perhaps would have been nice if the IniConfigSource had a constructor overload to pass in a CultureInfo object, to effectively tell it the culture of the file's contents.
I'd also like to know if there is something I'm missing, or some aspect of the above workaround that is is likely to bite me in the future!
Edit: looks like this line in ConfigSource is what enables my workaround to work, presumably picking up the current culture at the moment of instantiation?
IFormatProvider format = NumberFormatInfo.CurrentInfo;
Edit2: looks like this workaround only helps when reading files. When writing, numbers and dates are always written using the current culture.
The text was updated successfully, but these errors were encountered:
We have a desktop application that reads and writes numerous ini files that contain dates and numbers in UK format (en-GB). If we run the application on (say) a French PC then IConfig.GetDouble() throws a FormatException because it can't parse values in the file such as "1.23" (because the French use "," as the decimal point character). The nature of the app means we can only supply these ini files in UK format, and can't (for example) provide French customers with ini files that have been formatted to their locale.
As a workaround, I have found that I if I set the CurrentCulture to "en-GB" just before instantiating the IniConfigSource object, then back to the PC's region (e.g. French) right after creation, then I am able to read and write the file regardless of what the CurrentCulture is. I'm not sure how this is possible, but am assuming IniConfigSource stores the culture at the moment of its creation, then uses this during all read and write operations?
I was wondering if there is a more elegant solution to the above? It perhaps would have been nice if the IniConfigSource had a constructor overload to pass in a CultureInfo object, to effectively tell it the culture of the file's contents.
I'd also like to know if there is something I'm missing, or some aspect of the above workaround that is is likely to bite me in the future!
Edit: looks like this line in ConfigSource is what enables my workaround to work, presumably picking up the current culture at the moment of instantiation?
IFormatProvider format = NumberFormatInfo.CurrentInfo;
Edit2: looks like this workaround only helps when reading files. When writing, numbers and dates are always written using the current culture.
The text was updated successfully, but these errors were encountered: