Excusing the long post title referencing Dr. Strangelove, I’d like to point out a small bug with the SharePoint DateTimeControl. If you have ever implemented this control, you may find that you can set the MinDate property which is supposed to limit the range of dates allowed. However, doing so only limits the calendar popup associated with this control, but the user can still enter a date below the MinDate into the textbox (see comments in reference.)
I did a little searching on the interwebs and found the following post which described setting that textbox control read-only on the aspx page. Below you will find the code to make it read-only in the code behind.
DateTimeControl dtc = new DateTimeControl();
dtc.DateOnly = true;
dtcMinDate = DateTime.Today.Date;
((TextBox)dtc.Controls).ReadOnly = true;
In the last line, you will see that we are accessing a child control. At a basic level, the SharePoint DateTimeControl is just a wrapper for 4 controls: a date textbox, an hour and a minute dropdown, and a required field validator. Since the date textbox is the first control, we can cast it as a textbox and set the ReadOnly property and be all set.
Before: able to edit textbox
After: textbox is read only and calendar selection limited
One other note about the DateTimeControl. There is an issue with the SelectedDate property of the DateTimeControl not persisting through postback (reference 1 and reference 2). Example scenario: if you set the SelectedDate on page load, change the SelectedDate through UI, then have a page postback (perhaps for a required field validation on another control) your change to the SelectedDate will be lost and the original value from during page load will reappear. I have attempted all suggestions for enabling viewstate on parent container, removing Id, and clearing selection to no avail. My next steps will be to convert this over to an AJAXControlToolkit Calendar Extender implementation and see if that works. Expect a follow up post if that does fix the problem.
As you can see, the SharePoint DateTimeControl is a nice option since you’ll have access to it out of the box with SharePoint, but there are a few bugs to be aware of when deciding whether to use it or not. You might just be as well off building your own control to handle date selection. If you’ve run into any other issue or have suggestions for fixes to the problems above please leave some feedback below.
SharePoint DateTimeControl MSDN page
Make SharePoint DateTimeControl textbox read-only
DateTimeControl SelectedDate issue
DateTimeControl ViewState issue
2 thoughts on “Fixing the SharePoint DateTimeControl MinDate Property (or How I Learned to Make the DateTimeControl Read-Only and Love SharePoint Controls)”
Originally posted on: https://briantjackett.com/archive/2009/12/20/fixing-the-sharepoint-datetimecontrol-mindate-property-or-how-i-learned.aspx#499760Is the lost viewstate a common issue? or just an issue you have come across?I know you could technically look in the viewstate and grab the value out of there manually on page load.Let me know if you want the details on how to do that.
Originally posted on: https://briantjackett.com/archive/2009/12/20/fixing-the-sharepoint-datetimecontrol-mindate-property-or-how-i-learned.aspx#499811TC, The viewstate that is lost is something managed internally by the SharePoint DateTimeControl (and AjaxControlToolkit Calendar Extender.) I believe this is a known issue as I have found others reporting the same problem. Technically I could manage the viewstate myself externally and grab it’s value as needed, but that doesn’t fix either of these controls. I’m exploring other options at the moment. Thanks for the feedback.