DateTimePicker Control bug?

[linuxfedora]

I seem to be encountering what appears to be a bug in the
DateTimePicker Control using VS 2005. Follow these steps:

1. Create a new C# Windows Application project
2. Drop a DateTimePicker Control and a Button onto the form
3. Set the button as the form's AcceptButton
4. Add a Click handler for the button
5. Set a breakpoint inside the Click handler
6. Run the app in the debugger
7. Add a watch for the DateTimePicker Control's Value property
8. Type a single number over one of the number fields, such as the
day or year
9. Hit Enter
10. Notice inside the Click handler that the DateTimePicker
Control's Value property doesn't reflect the change

If I enter two numbers, such as '11' or '06' for the field, and then
hit Enter, I don't see the problem. Also, if the field loses focus
before I hit the Enter key, all is fine. Formally clicking the button
obviously does this and the problem is therefore not seen.

Has anyone seen this before? There's not a lot of complexity here, so
I'd tend to believe that this is a bug. Assuming it is, does anyone
know if this has been reported and is being fixed?

Thanks,

 

[Peter Duniho]

[...]
If I enter two numbers, such as '11' or '06' for the field, and then
hit Enter, I don't see the problem. Also, if the field loses focus
before I hit the Enter key, all is fine. Formally clicking the button
obviously does this and the problem is therefore not seen.

Has anyone seen this before? There's not a lot of complexity here, so
I'd tend to believe that this is a bug. Assuming it is, does anyone
know if this has been reported and is being fixed?

Before I spend any time trying to reproduce the issue (can't right now),
one obvious question is: can you reproduce a problem _without_ the
debugger? Do you have some specific reason to believe that at the point
in time that the Button instance's Click event is raised, the value
entered in the DateTimePicker control should in fact have been validated
and copied to the Value property?

You are right that there's a lot of complexity. There's an elaborate
set of rules of what is supposed to happen when, and frankly even those
rules seem to gloss over some of the corner cases, like validation when
a window is being closed, which may in turn depend on _how_ that window
is being closed. In the end, there may be a bug, but unless it simply
isn't possible to get things to work at all, it might not be worth
worrying about. And of course, it's possible it's working as intended,
just not the way you expect.

As far as whether it's a bug, known or not, Microsoft's Connect web site
is where you need to go to look for that. First thing to do is search
the bug database for the behavior (if you just search for
DateTimePicker, that probably will be a small enough collection of
search hits to narrow it down...of course, that's assuming the issue is
with DateTimePicker and not whatever edit field control it's using).

If after a thorough search you don't find anything, feel free to enter a
bug. The worst that can happen is Microsoft will look at it and tell
you it's working as designed. (I don't recommend this as a normal
form of customer support...obviously you should only report things you
believe to be bugs. But clearly you believe this to be a bug, and
absent spending a little more time with the question, I've no reason to
disagree).

Pete

 

[A. Walker]

I seem to be encountering what appears to be a bug in the
DateTimePicker Control using VS 2005. Follow these steps:

1. Create a new C# Windows Application project
2. Drop a DateTimePicker Control and a Button onto the form
3. Set the button as the form's AcceptButton
4. Add a Click handler for the button
5. Set a breakpoint inside the Click handler
6. Run the app in the debugger
7. Add a watch for the DateTimePicker Control's Value property
8. Type a single number over one of the number fields, such as the
day or year
9. Hit Enter
10. Notice inside the Click handler that the DateTimePicker
Control's Value property doesn't reflect the change

If I enter two numbers, such as '11' or '06' for the field, and then
hit Enter, I don't see the problem. Also, if the field loses focus
before I hit the Enter key, all is fine. Formally clicking the button
obviously does this and the problem is therefore not seen.

Has anyone seen this before? There's not a lot of complexity here, so
I'd tend to believe that this is a bug. Assuming it is, does anyone
know if this has been reported and is being fixed?

Thanks,

Couldn't reproduce this bug with SharpDevelop 3.1.0.4977.

 

[GrahameW]

I seem to be encountering what appears to be abugin theDateTimePickerControl using VS 2005.  Follow these steps:

   1. Create a new C# Windows Application project
   2. Drop aDateTimePickerControl and a Button onto the form
   3. Set the button as the form's AcceptButton
   4. Add a Click handler for the button
   5. Set a breakpoint inside the Click handler
   6. Run the app in the debugger
   7. Add a watch for theDateTimePickerControl's Value property
   8. Type a single number over one of the number fields, such as the
day or year
   9. Hit Enter
  10. Notice inside the Click handler that theDateTimePicker
Control's Value property doesn't reflect the change

If I enter two numbers, such as '11' or '06' for the field, and then
hit Enter, I don't see the problem.  Also, if the field loses focus
before I hit the Enter key, all is fine.  Formally clicking the button
obviously does this and the problem is therefore not seen.

Has anyone seen this before?  There's not a lot of complexity here, so
I'd tend to believe that this is abug.  Assuming it is, does anyone
know if this has been reported and is being fixed?

Thanks,

I had much the same problem and here's my workaround ...

In the form's OnAccept handler, check for the datetimepicker control
having the focus.
If it does, send it a right-arrow keystroke to force the control to
validate the partially entered value (ie the single digit)
the on accept handler will then be able to access the text/value
members of the control properly

eg

void OnAccept(...)
{
if (dtControl.Focused) // check your control for focus
{
SendKeys.SendWait("{RIGHT}"); // send keystroke to force
validation
}

// control now contains text/value as expected

...
}

NOTE: you must use the SendWait not the Send function so that the
control's validation/update is done immediately

There doesn't seem to be any adverse side effects, at least none that
I've come across yet.
It's a simple workaround and not too ugly - I've seen and done
worse ;-)

Good Luck

 

[linuxfedora]

I had much the same problem and here's my workaround ...

In the form's OnAccept handler, check for the datetimepicker control
having the focus.
If it does, send it a right-arrow keystroke to force the control to
validate the partially entered value (ie the single digit)
the on accept handler will then be able to access the text/value
members of the control properly

eg

void OnAccept(...)
{
    if (dtControl.Focused) // check your control for focus
    {
        SendKeys.SendWait("{RIGHT}"); // send keystroke to force
validation
    }

    // control now contains text/value as expected

    ...

}

NOTE: you must use the SendWait not the Send function so that the
control's validation/update is done immediately

There doesn't seem to be any adverse side effects, at least none that
I've come across yet.
It's a simple workaround and not too ugly - I've seen and done
worse ;-)

Good Luck

Hi GrahameW,

Thanks for your help, but i cannot find the OnAccept handle of the
form?Thanks