Hello,
When the Culture is set to "ar-SA" the calendar controls throw this error: "Week #N does not exist in year XXXX based on the current week rule ..."
http://i62.tinypic.com/11v1ukm.jpg
Hello Jorge,
Thank you for contacting Infragistics Support.
By setting the culture of your application to “ar-SA” you are switching from Gregorian calendars to UmAlQuraCalendar. This calendar is not fully supported by .NET framework. You may try to run the following snippet:
CultureInfo culture = new CultureInfo("ar-SA");
Thread.CurrentThread.CurrentCulture = culture;
try
{
int months = culture.Calendar.GetMonthsInYear(DateTime.Today.Year);
}
catch(Exception ex)
MessageBox.Show(ex.Message);
If you run that you’ll see that an exception is thrown. Please note that Infragistics controls support only Gregorian calendars.
Please let me know if you need any further assistance.
Is there any way to force the use of a Gregorian calendar (in “ar-SA” culture)?
I'm trying but is not working. There are Optional calendars in the culture, but it always uses the main calendar.
The only work-around I'm having success is change culture to one that uses a Gregorian calendar.
If (System.Threading.Thread.CurrentThread.CurrentCulture.Calendar.GetType() <> GetType(System.Globalization.GregorianCalendar)) Then 'Dim ci As New Globalization.CultureInfo(System.Threading.Thread.CurrentThread.CurrentCulture.LCID) ''ci.DateTimeFormat.Calendar = New System.Globalization.GregorianCalendar() 'ci.DateTimeFormat.Calendar = System.Threading.Thread.CurrentThread.CurrentCulture.OptionalCalendars(2) 'System.Threading.Thread.CurrentThread.CurrentCulture = ci ''System.Threading.Thread.CurrentThread.CurrentUICulture = ci
System.Threading.Thread.CurrentThread.CurrentCulture = New Globalization.CultureInfo("en-US") End If
Thanks much for that last explanation, it will come in handy when my testers ask me why the behavior is different now.
The 12.2 version of the control did not handle non-solar calendars any better than the currently supported versions. I believe we are now just catching certain exceptions so as to make the developer aware of the problem, whereas previously you weren't really sure what was going on.
We strive to never introduce regression issues across releases; if that calendar was supported in a previous version and no longer is, we would consider it a regression issue of critical severity. In this case, however, I think what you're seeing is a case of the old version's behavior misleading you into thinking it was working correctly.
Yes, this works! Thanks for the workaround here. Though I'm still not sure why Infragistics 12.2 handled the Saudi Arabian culture even without this workaround, while version 15.1 requires it.
I'm not seeing any difference between 14.2 and 15.1, although I'm not certain that I understood this whole thread.
The issue as far as I can tell is that the default calendar for the Arabic culture ("ar-SA") is a non-solar calendar, which is not fully supported by the .NET runtime, and not supported at all by our WinSchedule controls. Setting the CultureInfo.DateTimeFormat.Calendar property makes no difference, since the .NET runtime only looks at the CultureInfo.Calendar property.
Given that, one solution is to derive a class from CultureInfo which is based on the Arabic culture (see below), and override the (fortunately virtual) Calendar property to return a Gregorian calendar. Then assign an instance of this derived class to the System.Threading.Thread.CurrentThread.CurrentCulture property.
I tried this with both 14.2 and 15.1 bits and it works in both cases.
Any suggestions to solve my last post?