Find the current value of DateTimePicker control

[wjburke2]

For some reason beyond my understanding when I change the value of a DateTimePicker and press Tab in the Control validating event I can not find the value shown in the actual field. The validating event is triggered so I believe it knows the control is updated. but the value member shows the old value. I changed the control from 02/20/2019 06:00 AM to 02/20/2019 05:00 AM. Then hit the Tab key. How do I access the current value of the field. The new value?

    
Private Sub dtpLogIn_Date_Validating(sender As Object, e As System.ComponentModel.CancelEventArgs) Handles dtpLogIn_Date.Validating

        Dim dtOldValue As DateTime = dtpLogIn_Date.Value ' <-- This still shows 02/20/2019 06:00 AM 

        'Dim dtNewValue As DateTime = dtpLogIn_Date
        If Not IsDate(dtpLogIn_Date.Value) Then
            GoTo validatiigExit
        End If

validatiigExit:

End Sub

[Shaggy Hiker]

I can't reproduce that behavior. Which version of VS are you using?

It appears that you are using a custom format, so I tried that, too, and I thought I saw one case where the result was totally wrong, but I believe I was mistaken about that as I haven't been able to recreate it.

By the way, why are you checking whether or not a date is a date?

[wjburke2]

I am using VS2015, The field is bound to a table. I am using a Custom format of "MM/dd/yyyy hh:mm tt". I believe it did work once if I type '05' rather than just '5' in the hours portion of the date. About the date check, I was just curious if perhaps it thinks its a bad date with 5 not 05. I do notice that after tabbing out of the field if I return to the field then hit tab again it has the changed value. So here is where I am confused if the value has been changed and shows on the screen why is it not updating the program storage area?

'dtpLogIn_Date
'
Me.dtpLogIn_Date.CustomFormat = "MM/dd/yyyy h:mm tt"
Me.dtpLogIn_Date.DataBindings.Add(New System.Windows.Forms.Binding("Value", Me.Shift_LogBindingSource, "SL_LogIn_Date", True))
Me.dtpLogIn_Date.Format = System.Windows.Forms.DateTimePickerFormat.Custom
Me.dtpLogIn_Date.Location = New System.Drawing.Point(172, 71)
Me.dtpLogIn_Date.Name = "dtpLogIn_Date"
Me.dtpLogIn_Date.Size = New System.Drawing.Size(149, 20)
Me.dtpLogIn_Date.TabIndex = 4

[wjburke2]

A quick update. I put a display in the dtpLogIn_Date_ValueChange event the value is the new value there. A couple of problems with this, Valuechanged fires after the Validating event. The ValueChanged event fires all the time. Is the validating event therefore a useless event as it will be validating the old value?

[Shaggy Hiker]

Validating isn't useless, but it is a bit peculiar. The purpose for that event is to give you a chance to push the user back to the control with a warning if the value isn't valid. I assume that you're going to do your validating against whether the start is before the end, which may or may not be a good idea. After all, the user may have set one, with the intention of setting the other, but validating will fire when they attempt to set the other, and if the validation rule fails, they'll be pushed back to the first. That makes the event of very specific, rather than general, value. People use it when it makes sense, and it often does not. I've only used Validating for a few things, and I kind of think that this wouldn't be one of them.

Of course, what's the alternative? Value Changed is one option, but it might be no better. If you really are trying to compare that start is before end, you have to give the user a chance to address both, which means that validation can't really occur until MUCH later, which usually means when something like a FINISHED button, or some other "move on to the next page" action is taken. It's not ideal, but then again, you can't truly predict the actions of the user, so nothing is necessarily ideal.

[wjburke2]

Actually at this point I am trying to see if the date fits with the employee scheduled hours. When they hit save I will do a full validation. But the fact remains that the value in the field during validating is the old value before the changes. The new value is not available until after the ValueChanged event. I really think the VS developers failed.We have a validating event that only fires when the value changes but exposes the unchanged value, and a ValueChanged that fires every time the wind blows across the screen but exposes the changed value.

Dim dr As LazerMaintenanceDataSet.OperatorsRow
dr = LazerMaintenanceDataSet.Operators.FindByInitials(ComboBox1.SelectedValue)
Dim StartTime As TimeSpan = dr.Start_Time
Dim tsHours As TimeSpan = TimeSpan.FromHours(dr.Hours)

Dim dtNewValue As DateTime = dtpLogIn_Date.Value

Dim tsStartTime As TimeSpan = dtpLogIn_Date.Value.TimeOfDay
Dim dtStartDate As Date = dtpLogIn_Date.Value.Date

If tsStartTime < StartTime Then
If (MsgBox("Your login time is before your normal login time?",
MsgBoxStyle.OkCancel, "Confirmation") = MsgBoxResult.Cancel) Then
dtpLogIn_Date.Value = dtOldValue
GoTo validatiigExit
End If
End If

[wjburke2]

Anyway I guess this will just be another winforms fail

[Shaggy Hiker]

Except that, thus far, it is only happening to you. The one piece I haven't replicated is the data bound part. That may be related, as the new value may not propagate out to the binding until after validating has taken place, and the control has the bound value...or something like that. It would have to, I think, since you can refuse the validating and the value should revert to the current, which is the bound value. I suspect that if you unbound that control as a test, the behavior would likely change to what you are expecting. If that were to be the case, you'd have to decide whether you could live with the extra step of putting the data into the datasource yourself rather than relying on the binding. I don't believe that would be difficult, but there are so many different ways you could source the data that there may be alternatives that make it difficult.

[Inferrd]

@Shaggy Hiker:
I can replicate this behaviour, and I suspect you can too...

While using the custom format, make sure it's PM (not tried AM to be honest) and then select just the hour component. Type a single digit and then press the TAB key.

So for example, with the custom format the DTP is showing 05/23/2019 11:41 PM

Type 3 for the hour value and press TAB. The validating event will be raised but dtpLogIn_Date.Value will still be #5/23/2019 11:41:26 PM#

Now type 7 for the hour value and press Tab. In the validating event, dtpLogIn_Date.Value will now be #5/23/2019 03:41:56 PM#, not 07:41:56 PM

Typing 2 digits for the hour value does not give the same problem.


@wjburke2:
There's a hacky solution for this and similar problems:

Private Sub DateTimePicker1_Validating(sender As Object, e As CancelEventArgs) Handles dtpLogIn_Date.Validating
    BeginInvoke(Sub() DoDtpValidation())
End Sub

Private Sub DoDtpValidation()
    Dim dtOldValue As DateTime = dtpLogIn_Date.Value ' <-- This will now reflect the value displayed in the DTP

    'Dim dtNewValue As DateTime = dtpLogIn_Date
    If Not IsDate(dtpLogIn_Date.Value) Then
        GoTo validatiigExit
    End If

validatiigExit:
End Sub

[Shaggy Hiker]

I'll have to give it a try when I get back to that computer. I really thought I HAD tried that and found it to be working fine for me, but I'll follow your step-by-step approach and see what happens.

[topshot]

In VS2013 I agree the DTP.Value does not change until the ValueChanged event fires AFTER the Validating event when using Tab, which causes the Leave event to fire. So in that case it does:
Leave
Validating
Validated
ValueChanged
LostFocus

Entering 2 digits or using arrows to change the value keeps you in the control so the ValueChanged event fires with correct Value since you aren't leaving the control. It seems like a bug to not to check for ValueChanged before Validating if you are leaving a control.

[wjburke2]

It seems like a bug to not to check for ValueChanged before Validating if you are leaving a control.

I agree, and have contacted Microsoft regarding this bug we will see if they agree and fix it.
Microsoft Support did come up with a work around Disable and then enable the control before you check the value. This forces the ValueChanged to fire updating the value. Hokie but it worked for me