I recently updated from 2010 Q1 to 2011 Q3. I have several DateTimePickers throughout my application, and the vast majority have these settings: MinDate = 01/01/1900; NullDate = 01/01/1900; NullText = "Not Selected"; Text = ""; Value = 01/01/1900.
Users started reported some odd errors, and when I eventually tracked them down, I realized that the Value of the DateTimePicker controls was often being reset to whenever I opened the forms/user controls containing those DateTimePickers in the designer. The TEXT, however, was NOT changing (making it difficult to spot without manually investigating the properties of each DateTimePicker). When I would try to change the Value back to 1/1/1900, the change would not be accepted, instead reverting back to the Now time from before. However, if I changed the time to some other value, then back to 1/1/1900, it would accept it. Then, if I opened the form again, the Value would stay at 1/1/1900.
I have fixed this problem for my application through 2 methods: 1) In my base form and base user control, used by everything else, I loop through all the controls and set the Value to 1/1/1900 (prior to any other activity with those controls); 2) I opened every form in my application and reset the dates. Though 1 should certainly be sufficient, I didn't like the idea that simply opening a form would change code, so I wanted to get that taken care of.
So, I have this first application working, but now I'm about to go through the laborious process of upgrading several others to this version of the controls, and I suspect I will have the same issue. I'm hoping you guys have an idea what is going on.
My own thoughts were that maybe a) having MinDate and NullDate as the same value was somehow bad (see the wrongly posted small section in http://www.telerik.com/community/forums/winforms/calendar-and-datetimepicker/raddatetimepicker-does-not-work.aspx
for an implication that this could be an issue) or b) RadDateTimePicker defaults to Now when added to a form/control, and it uses some value normally set in the more recent version to tell if this DateTimePicker was just added. B seems more likely to me because that would explain how manually changing the time in the designer to another value, then changing it back to 1/1/1900, would work -- some value is being set then, and now the DateTimePicker realizes it is not newly added, so it "sticks." Or ... maybe it is a combination or those, or something else entirely.