DateTimePicker setting itself to Now when form opens

[Taylor]

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.

Thoughts?

[Peter]

Hello Brandon,

Thank you for writing.

RadDateTimePicker is one of the first components in our suite, it had a lot of legacy code in it and it was very hard to maintain. That is why it has been completely re-designed in Q2 2011.

Now RadDateTimePicker supports Null Value (by NullableValue property) and you can set directly Null, for the value, for example:

radDateTimePicker1.NullText = "Not Selected"
radDateTimePicker1.NullableValue = null;

So my suggestion is to avoid using of NullDate.

I am not sure that I fully understand what you mean by "it uses some value normally set in the more recent version to tell if this DateTimePicker was just added."? Could you clarify what is your scenario and what do you want to achieve?

I strongly recommend using Q3 2011 (v2011.3 11.1116) version.

All the best,
Peter
the Telerik team

[Taylor]

We are using Q3 2011, so I'm happy to oblige you there.  :-)

For this application (which is pretty large, 100k+ lines of code), I would prefer not to have to change all of the date logic ... though we may go down that route in the future, and likely will for our other applications as part of the upgrade.  NullDate has not been marked as obsolete, has it?

Can the NullableValue be any value?  We are coding in VB, so should it be Nothing, or DBNull, or something else?

For the part where I was unclear, I was guessing what would cause the value of the DateTimePicker to change when the form was opened in the designer.  One of my thoughts there was that the DateTimePicker might have been "confused" and thought it had just been added to the form, so it set itself to Now.  I was speculating that the DateTimePicker might default to Now when certain properties were not set in the designer, so when I manually changed the date, those properties were set, so this behavior stopped.

Thanks for your quick reply, by the way.

[Peter]

Hi Brandon,

Thank you for writing back.

NullDate is not marked as obsolete yet, however I recommend to use NullableValue instead. For more information please, read this help article.

NullableValue is the same as the Value property, but the NullableValue property is of type Nullable DateTime. It can be null/nothing – in this case if RadDateTimePicker is not selected it will show its NullText. In case RadDateTimePicker is selected, it will show the last entered date – this allows the end-user to enter and edit the date.

The default value of RadDateTimePicker is the value of DateTime.Now so if you do not set explicitly the Value at design time the Visual Studio designer will update the value of this property.

I hope this helps.

Greetings,
Peter
the Telerik team

[Taylor]

I'm marking the above response as the answer because it gave me as much information as I can hope to get without me creating a sample app to show my question in more detail (which I'm not going to do :-)  ).

I think that, after a manual update, the DateTimePicker controls suddenly thought they were newly added again when the containing forms were opened in the designer, even though they had been there for a couple of years, in most cases.  My gut feeling is that the combination of NullDate and Value being set to 1/1/1900 made each instance of RadDateTimePicker think that no value was set, so it defaulted it to Now.  Toggling the value to something else, then back to 1/1/1900, reset the Value property, so that behavior disappeared.

Moving forward, we will probably use NullableValue as we make changes.

Thanks for the replies.

[Peter]

Hi Brandon,

I am happy to hear that you resolved the issue.

Do not hesitate to write me back if you have further questions.

Greetings,
Peter
the Telerik team