DateDiff, DateAdd Alternativen zum VisualBasic Namespace

  • VB.NET
  • .NET 4.5

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von eichseinet.

    DateDiff, DateAdd Alternativen zum VisualBasic Namespace

    Hallo zusammen.

    Gestern sollte wie in einem Beitrag hier im Forum beschrieben alles aus dem VisualBasic-Namespace aus meinem Programm entfernt werden. Dabei stosse ich aber auf Widerstand. :)
    Zuerst wurde im Projekt der Verweis auf den Namespace entfernt. Beim Erstellen der Projektmappe erscheinen nun eine Menge Fehler. (wie erwartet)
    DateDiff, DateAdd und Now scheinen alle aus diesem (laut Beitrag) veralteten Namespace zu stammen. Aber wie lauten die korrekten Alternativen und wo findet man sie?

    Gruß

    eddi
    Den Thread Böses aus VB6/VB2003 - und die richtigen VB.NET-Alternativen bist Du durch? Beispiel: Now -> Date.Now
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.
    das behandelt man anders.
    Man kann Zeiten ganz normal addieren, subtrahieren.
    Zu beachten: Einen Zeitpunkt (Date) kann man nur mit einer Zeitspanne (TimeSpan) verrechnen.
    (Was höchst logisch ist: Weihnachten.2001(Datum) + Weihnachten.2004 - was soll das ergeben? ZweiWeihnachten.4005?
    Sinnvoll ist: Weihnachten(2001) + 3Jahre (eine Zeitspanne)) ergibt Weihnachten.2004)

    VB.NET-Quellcode

    1. dim whncht2004 = new Date(2001,12,24) + TimeSpan.FromYears(3)


    Weiters haben Date und Timespan viiiele Objekt-Methoden, sowas wie .AddDays(double) etc. Schau dir das im ObjectBrowser gründlich an.
    Oder poste BeispielCode, wo du auf keine oder nur auf eine umständliche Lösung kommst.
    Ja genau.



    Btw: Man muss nicht in jeder Deklaration New davor-schreiben.
    Sondern nur in Deklarationen, wo man auch gleich ein neues (New!) Objekt erzeugt.
    Bei dir das Zeitspanne wird ja erst in #5 erzeugt - die Initialisierung in #3 ist also üflüssig (und zudem noch ohne Daten-Übergabe - also welche Zeitspanne wird der Timespan habe?)

    Also nochmal: Deklaration und Initialisierung sind grundsätzlich zwei unterschiedliche Dinge.
    Vereinfachend können (müssen aber nicht) sie auch in einer Zeile formuliert sein (zB #1, #2)

    In Zeilen #3, #5 sind Deklaration und Initialisierung aber getrennt. Daher nicht statthaft, in #3 eine (datenlose) Initialisierung durchzuführen.

    Ist konkret egal, aber ich sehe sowas öfters bei "teuren" Objekten oder welchen, die disposed werden müssen (und dann nicht werden).
    Oder auch, wenn die richtige Initialisierung beabsichtigt ausgelassen wird. Dann wirkt ein überflüssiges New dergestalt, dass da ein (datenlos initialisiertes) Objekt vorliegt, wo keines sein sollte.
    Solche Objekte verhalten sich dann sehr unerfreulich, und der eigliche Fehler - das üflüssige New lässt sich oft auch nur schwer finden.
    dim whncht2004 = new Date(2001,12,24) + TimeSpan.FromYears(3)?
    Naja, ich würde es eher so machen:
    Dim Weihnachten2004 = New Date(2001, 12, 24).AddYears(3)

    und

    VB.NET-Quellcode

    1. Dim erstesDatum = New Date(2020, 09, 15)
    2. Dim zweitesDatum = New Date(2020, 09, 16)
    3. Dim Zeitspanne = zweitesDatum - erstesDatum
    4. Dim ZeitspanneInStunden = (zweitesDatum - erstesDatum).TotalHours

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Häufig von mir verwendete Abkürzungen: CEs = control elements (Labels, Buttons, DGVs, ...) und tDS (typisiertes DataSet)
    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht in den Spekulatiusmodus gehen.