Understanding Design Decisions for Calendar and DatePicker

Dec 2, 2008 at 9:44 PM

The information currently available to WPF/Silverlight control developers is greatly lacking.  Other than the basics discussed as part of a chapter in one of the main WPF books, there is not much out there.  Supplying the source to the toolkit is great, but it leaves many questions unanswered.  When is someone at Microsoft going to create a book just on WPF/Silverlight control development?

I am writing a control that can either work standalone or in a popup of a control in a similar manner as Calendar and DatePicker.  I thought it would be really easy to add the DatePicker like functionality, but it is harder than I thought. 

Questions & Observations:

  1. Why is DatePicker a separate control inherited from Control rather than inherited from Calendar with a different template?
  2. When a property on Calendar is also exposed by DatePicker what are the options for connecting them?  When would it be best to choose which option?
  3. Both Calendar and DatePicker have the following properties: DisplayDate, DisplayDateEnd, DisplayDateStart, FirstDayOfWeek, IsTodayHighlighted, and SelectedDate.  Why is FirstDayOfWeek and IsTodayHighlighted the only common properties set using SetBinding in the InitializeCalendar method?
  4. I see that when DatePicker needs to validate a property that is also on Calendar (ex: FirstDayOfWeek) that is just calls Calendar.IsValidFirstDayOfWeek.  That makes sense.
  5. Why does the SelectedDate property on DatePicker have a CoerceValueCallback when the SelectedDate property on Calendar does not?
  6. Both DisplayDateEnd and  DisplayDateStart define a PropertyChangedCallback and a CoerceValueCallback for both Calendar and DatePicker.  Why? How are these properties different than DisplayDate and SelectedDate?
  7. What is the purpose of AutomationPeers?


There are probably more questions to ask, but that is where I am right now.