Hi,
I’m using that code (the meaningful part):
Application.CurrentCulture = getCulture();
public static System.Globalization.CultureInfo getCulture()
{
System.Globalization.CultureInfo ci = new System.Globalization.CultureInfo(“en-US”, true);
//Dim ci As New System.Globalization.CultureInfo(“ro-RO”, True)
ci.NumberFormat.NumberDecimalSeparator = “.”;
ci.NumberFormat.NumberGroupSeparator = “,”;
ci.NumberFormat.NumberDecimalDigits = 2;
ci.DateTimeFormat.FullDateTimePattern = “dd.MM.yyyy HH:mm:ss”;
ci.DateTimeFormat.ShortDatePattern = “dd.MM.yyyy”;
//ci.DateTimeFormat.ShortDatePattern = “yyyy/MM/dd”;
ci.DateTimeFormat.ShortTimePattern = “HH:mm:ss”;
ci.DateTimeFormat.FirstDayOfWeek = DayOfWeek.Monday;
return ci;
}
In DatagridView, when displaying date columns, it takes ShortDateFormat from Region settings (in Windows client) and ignores my setting.
Am I doing something wrong?
I see. What happens is that when a new thread is used from the thread pool is always starts at “en-US” (the invariant one) if the server uses the default language. When working on a desktop app you have only 1 main thread and when you change the thread culture it stays.
In a web app each request gets a thread from the pool and the thread’s culture info has to be updated on each request (if the system supports full localization, like Wisej does). The locale can be different on each request because of user settings or because the app changed it (like in your case) and Wisej cannot just change the thread’s culture on each request because it would just take unnecessary time so it checks if it has really changed and the only way to check is using Equals(). But, in .NET CultureInfo.Equals checks the name only. In addition there are so-called IsNeutralCulture CultureInfo (i.e. “ro” is neutral while “ro-RO” is not, “en” is neural, “en-EN” is not neutral). When the culture is neutral Wisej checks the ThreeLetterISOLanguageName to see if the culture is changed.
Anyway, the best way is to use the sample I sent you and change it like this:
Application.CurrentCulture = new ApplicationCulture(“en-XX”);
It will base it on “en” and creates your own version of “en”. Be sure to set the CurrencySymbol otherwise is uses a placeholder character.
I will see if we can improve the switch detection by checking Equals() from the value being set instead of the existing value to allow a custom MyCultureInfo class to override it. But creating a custom name is always the best approach.
Hi Luca, implement what is indicated in my project but I still have problems with the date format, check the attached image, in column (0) using ShortDate the display is corrected, add a column (2) text with “InputType = Date” and it does not display correctly as I show in the image … when you take the focus and enter the format ok, but when you lose the focus it changes to the yyyy-MM-dd format …
The TextBox control does not respect the applied date format, but if it is typed and at the moment of losing the focus if it respects the format.
Thank you…
It works perfectly on my development machine. On server I got the error attached. Any clue?
Same error with en-UK
Yes, I get the same result. But that’s not the problem. I’m sorry I’m misleading you.
ro-RO works ok for dates, but there are other inconveniences (like number separator, text sorting, etc).
That’s why I want to start from en-US and modify just .
See the attached picture.
See attached. I just copied the settings in your last comment. Let me know if it works for you.
Here is a third way to achieve the same. This one allows you to set the same culture multiple times since Equals() checks for the instance identity and it’s cleaner IMO since you can set your custom changes in one place.
Application.CurrentCulture = new MyCulture("ro-RO");
public class MyCulture : CultureInfo { public MyCulture(string name) : base(name, true) { this.NumberFormat.CurrencySymbol = "#"; } public override bool Equals(object value) { return this == value; } }
WinForms and VWG don’t have Application.CurrentCulture. You can change the culture on the current thread without checks. Wisej checks if it’s the same culture using culture.Equals() which checks the name of the culture before altering the culture which triggers several updates in Wisej that are all missing from VWG and work differently on WinForms since the desktop is the same machine as the “server”.
I tried these two options and both work well:
Program.Main() { var ro = new CultureInfo("ro-RO", true); ro.NumberFormat.CurrencySymbol = "#"; Application.CurrentCulture = ro; }
Program.Main() { var ro = (CultureInfo)CultureInfo.GetCultureInfo("ro-RO").Clone(); ro.NumberFormat.CurrencySymbol = "#"; Application.CurrentCulture = ro; }
If you set culture=”ro-RO” also in default.json you are setting the culture twice, the first time using the original “ro-RO” and then programmatically again but using the same culture (same name). Just set your modified culture the first time at startup.
Hi Luca,
After several testing and discussions with final client I’m still in trouble. I got your point, and I can change the culture with an existing one (in my case, ro-RO). The problem is that my client (and not only that client) want a mixture of settings (en-US as base with different date format, and some other differences). Every way I tried to create a new one by code failed.
In both winforms and Webgui the code I provided in my first post is working. In Wisej it’s not, and I didn’t find until now a workaround.
Please help!
My purpose is to take “en-US” culture and change just ShortTimePattern. Can you please give me some code lines doing that?
What I don’t understand is that behaviour:
CultureInfo ci= getCulture(); //that function clone a culture and change ShortDatePattern
Application.CurrentCulture = ci; //I expect after that line to have in Application.CurrentCulture the same settings
Still, even in debuger, after the second line I got:
?ci.DateTimeFormat.ShortDatePattern
“dd.MM.yyyy”
?Application.CurrentCulture.DateTimeFormat.ShortDatePattern
“M/d/yyyy”
The issue is that you are changing “en-US” without changing the name and .NET compares only the name in System.Globalization.CultureInfo.Equals(). If you create a new culture you need to give it a new name – or use a sub name, like “en-XX”.
Usually there is no reason to create a new culture, they are all already implemented in Windows, you can simply assign CultureInfo.GetCultureInfo(“ro-RO”). Or set it in default.json (default is auto, it’s detected from the browser), or add to the URL “?lang=ro-RO”.
Or you can try to assign a different culture and then your modified culture to bypass the Equals() check.
Please login first to submit.