[RESOLVED] A date variable refuses to get today

[pourkascheff]

Hi all o7. How is the correct way to update a date variable?

Following code does a cycle every seconds (lots of things happen here which are commented for now) in 24th hour of the day, yesterday ≠ today will happen and calibration/registration check [at its simplest way] will take place. After checking and analyzing things (which is not the case) yesterday variable should become today to avoiding it to happen next seconds for that day. But it is not happening. The debug msgbox (it's not necessary for final app) will always indicate "01/01/0001" obviously "yesterday" will not follow the term "Today".

Public Class FORMTEST
    Dim YESTERDAY As String
    Private Sub Timer1_Tick(sender As Object, e As EventArgs) Handles Timer1.Tick
    'COMMENTED CODE
        If YESTERDAY IsNot Today.ToShortDateString Then
            MsgBox(YESTERDAY & vbNewLine & Today.ToShortDateString)
            'THINGS ALSO HAPPEN HERE IN THE FUTURE
            YESTERDAY = Today.ToShortDateString
        End If
    End Sub
End Class

Additional question: "Today" is present in Date.Today, DateAndTime.Today and DateAndTime.Today with different accent colors. What are their differences?

What I've tried:
- Me.Invoke(Sub() / End Sub) Not sure why I did that but thought this is the matter of graphics update (codes in prior)
- Commenting all prior codes = same result.
- Tried both String type and date actual format = same result. Code is in string type I assume string is always simpler.
- Tried YESTERDAY = New Date(Today).ToShortDateString seems the dictation is faulty.

[PlausiblyDamp]

As a quick fix try

  If YESTERDAY <> Today.ToShortDateString Then

IsNot compares object references, not the values of the two objects - you want to be comparing the contents of two strings, not checking if two variables point to the same string.

However I would avoid the string conversions and just compare the dates directly anyway e.g.

Dim _yesterday As Date = Date.MinValue

Private Sub Timer1_Tick(sender As Object, e As EventArgs) Handles Timer1.Tick
    'COMMENTED CODE
    If _yesterday.Date <> Date.Today.Date Then
        Debug.WriteLine($"{_yesterday} - {Date.Today.ToShortDateString}")
        'THINGS ALSO HAPPEN HERE IN THE FUTURE
        _yesterday = Date.Today
    End If
End Sub

[jmcilhinney]

Small thing but there's no point using Date.Today.Date. Date.Today already has the time zeroed because it is implemented as Date.Now.Date.

[PlausiblyDamp]

Small thing but there's no point using Date.Today.Date. Date.Today already has the time zeroed because it is implemented as Date.Now.Date.

Good point, in my defence I hadn't had a coffee when I typed that

[pourkascheff]

Well, thanks for good points. I even tried formating .ToString("MM/dd/yyyy") but it turned out the problem was the order or msgbox being prior to making yesterday equal to today. Instruction line never reaches to yesterday = today line unless you press OK on msgbox.

Consequently, my first approach was OK. Debug.WriteLine is always better... [sigh]

[PlausiblyDamp]

Well, thanks for good points. I even tried formating .ToString("MM/dd/yyyy") but it turned out the problem was the order or msgbox being prior to making yesterday equal to today. Instruction line never reaches to yesterday = today line unless you press OK on msgbox.

Consequently, my first approach was OK. Debug.WriteLine is always better... [sigh]

I would always avoid using MsgBox (or Messagbox.Show as we are using .Net) for debugging purposes. A messagebox disrupts program flow, needs to be clicked to dismiss (which loses the information displayed), and needs to be removed once you have debugged. Debug.WriteLine and similar get round all of those issues, and the compiler will strip the code in a release build as well.


A couple of other minor points...

Firstly I would avoid using the legacy VB6 language constructs such as vbNewLine, MsgBox, etc. and prefer the framework alternatives if you are using dotnet then it makes more sense to use the dotnet methods and not the compatibility wrappers.

Secondly, I would consider adopting a naming convention more closely aligned with dotnet itself, variable and class names in ALLCAPS are difficult to read - https://learn.microsoft.com/en-us/do...ing-guidelines is the naming convention used by MS and I would normally suggest following it for your own code, that way you don't need to keep two different conventions on the go.

[pourkascheff]

Warm appreciation for those tips. Where can I find newer .NET things? Yes, I'm a 90's kid, I used to VB6 as slang it might change my programming skills dramatically. Thanks in advance.

[PlausiblyDamp]

Warm appreciation for those tips. Where can I find newer .NET things? Yes, I'm a 90's kid, I used to VB6 as slang it might change my programming skills dramatically. Thanks in advance.

I would just avoid using anything from the Microsoft.VisualBasic namespace as this is where most of the compatibility functions live.

Under dotnet it is rare that you will call a function directly, dotnet being an object orientated language means all methods etc. belong to a Type (quite often a class), so whenever you find yourself using a function directly e.g. MsgBox(), Left(), Format(), Now(), etc. it is a good sign that this is a compatibility method.

Often you will find the equivalent functionality as either part of a dotnet type e.g. MessageBox.Show(), Date.Now, etc. or as a method on the variable e.g. strings having a .SubString(), .ToString() method etc.