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
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?