Multiple Event Firings when Validating the Date in a DateTimePicker Control

We developed a .NET application which among other things enabled the CSR’s to set the requested service start date for customers utilizing a DateTimePicker control.  If this requested service start date happens to fall on the weekend, the application shall then move it forward to the first business day following the weekend.  It shall also display an alert message box informing the CSR’s of this date change.

The first thought that came to mind for displaying the alert message box was to capture the date modification in the ValueChange event, for the simple reason that this event got raised when we changed the value in the DateTimePicker control.  Therefore, assuming that the DateTimePicker control was named dtRequested and that the processing logic to move the date forward was contained in a procedure called setSODefaultDate, we proceeded to code the following to handle the ValueChange event:

private void dtRequested_ValueChange(object sender, EventArgs e)
{
if (((int)dtRequested.Value.DayOfWeek == 0) | ((int)dtRequested.Value.DayOfWeek == 6))   // Sunday(0) or Saturday(6)
{
DialogResult m_dr =  MessageBox.Show("Weekend selection for Date Requested is not allowed.  The selected date has been moved forward to the next business day);

setSODefaultDate(dtRequested.Value, false);
dtRequested.Select();
}
}

Simple enough!  We thought for sure that the only thing left to be done was to compile and did a simple test just to make sure that we didn’t mess anything up.  But it DID NOT work!  When we tested the application by setting the date to fall on the weekend, we first saw the alert message box indicating that the weekend selection was not allowed.  We then clicked the OK button on the message box to dismiss it.  To our surprise, the message box disappeared, but then it immediately reappeared!  We clicked on the OK button again, and this time, the message box disappeared for good.  What happened there?

As it turned out, the problem with validating the DateTimePicker control using its validation event was that, if the validation included confirmation of the change, the validation event would fire twice. The first validation would occur when the actual date change took place, which got triggered when the CSR’s changed the date from the default today’s date to a future date to accommodate the requested start service date from the customer.  The second validation would occur when the date was automatically moved forward to the next business day, assuming that the previously selected service start date fell on the weekend. To that end, the CSR’s were treated to viewing the message box twice in a row.  In order to avoid this issue, we needed to utilize, instead, the CloseUp event, which occurred when the DateTimePicker control was dismissed.  Thus, the event handling code needed to be coded as follows:

private void dtRequested _CloseUp(object sender, EventArgs e)
{
if (((int)dtRequested.Value.DayOfWeek == 0) | ((int)dtRequested.Value.DayOfWeek == 6))   // Sunday(0) or Saturday(6)
{
DialogResult m_dr =  MessageBox.Show("Weekend selection for Date Requested is not allowed.  The selected date has been moved forward to the next business day);

setSODefaultDate(dtRequested.Value, false);
dtRequested.Select();
}
}

In conclusion, the problem with validating the control using its validation event is that, if the validation includes confirmation of the change, the validation event will fire twice. In order to avoid this issue, we instead need to capture and process the CloseUp event.