by Michael S. Kaplan, published on 2005/03/28 02:19 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/28/402839.aspx
The issue is partially described in the Microsoft Knowledge Base (article 889834) but this article does not tell the full story (and some of what it tells is wrong).
Let's start with the title and its problems between CurrentUICulture and CurrentCulture:
The DateTimePicker control and the MonthCalendar control do not reflect the CurrentUICulture property of an application's main execution thread as you expected when you created a localized application in the .NET Framework or in Visual Studio .NET
Now the MonthCalendar and the DateTimePicker are not based on the UI settings, they are based on the user settings. So even if the control is fully globalized, it would never be based on the UI settings. This is because the date, time, calendar, number, currency, and collation settings are always based on the default user locale (and on CurrentCulture in the .NET Framework). If a localized application's language were to match this, it would only because the user happened to set CurrentCulture and CurrentUICulture to be the same culture, which is often the case but does not have to be.
Now the article is smart enough to point out the user locale settings control the language of the DateTimePicker and the MonthCalendar controls, and it does point out why -- because these two controls are wrappers around the Windows Shell common controls.
But this is not the full story.
Because calendars, as imperfect as they are in Win32 (cf: Calendars on Win32 -- just there for show...., Calendars on Win32 -- Not all there yet) and .NET (cf: Calendars.NET -- new platform, new issues) both platforms have serious advantages over the Shell controls, since the Shell DateTimePicker and MonthCalendar common controls only support the Gregorian calendar.
Thus even if your default user locale settings include a calendar setting where GetLocaleInfo with the LOCALE_ICALENDARTYPE returns any of the following values:
Value Constant Meaning
1 CAL_GREGORIAN Gregorian (localized)
2 CAL_GREGORIAN_US Gregorian (English strings always)
3 CAL_JAPAN Year of the Emperor (Japan)
4 CAL_TAIWAN Taiwan calendar
5 CAL_KOREA Tangun Era (Korea)
6 CAL_HIJRI Hijri (Arabic lunar)
7 CAL_THAI Thai
8 CAL_HEBREW Hebrew (Lunar)
9 CAL_GREGORIAN_ME_FRENCH Gregorian Middle East French calendar
10 CAL_GREGORIAN_ARABIC Gregorian Arabic calendar
11 CAL_GREGORIAN_XLIT_ENGLISH Gregorian Transliterated English calendar
12 CAL_GREGORIAN_XLIT_FRENCH Gregorian Transliterated French calendar
the DateTimePicker and MonthCalendar controls will never go beyond the Gregorian calendar.
Now the methods and properties on the calendar classes derived from Calendar class (GregorianCalendar, HebrewCalendar, HijriCalendar, JapaneseCalendar, JulianCalendar, KoreanCalendar, TaiwanCalendar, and ThaiBuddhistCalendar) contain the capabilities to let you create your own calendar. I'll try and throw such a sample of a calendar together another time.
Note that the above limitations do not apply to the ASP.Net control (System.Web.UI.WebControls.Calendar). I will cover this control and its capabilities another day....
This post brought to you by "ฟ" (U+0e1f, THAI CHARACTER FO FAN)
# Michael Kaplan on 28 Mar 2005 7:44 AM:
# Anand on 7 Apr 2005 11:16 PM:
# Michael S. Kaplan on 7 Apr 2005 11:26 PM:
# Brad Eck on 16 Jun 2005 4:30 PM:
# Michael S. Kaplan on 16 Jun 2005 7:04 PM:
go to newer or older post, or back to index or month or day