'Ungültiges Argument zum Codieren des Datums'

[Delbor]

Hi zusammen
Der Titel nimmt schon mal die Fehlermeldung vorweg. Besonders erstaunt bin ich allerdings nicht. Sinnbildlich kann man sich einen Spiegel vorstellen, indem man den Spiegel hinter sich erblickt, indem man... und so fort.Debuggen bringt folgendes:

Zitat:

Im Projekt TerminkalenderProject.exe ist eine Exception der Klasse EConvertError mit der Meldung 'Ungültiges Argument zum Codieren des Datums' aufgetreten.

Klicke ich auf Anhalten, ergibt sich folgendes Bild:
Anhang 53228
Von interesse ist hier der Einsprung in die Scheife:

Delphi-Quellcode:

   LmD := DaysInMonth(ADate);          //  while i <=6 do          IntToStr(Dies schreibt 7 Wochenblöcke ins Stringgrid)
   while DayOfTheMonth(Datum) < LmD +1 do

ursprünglich hiess das:

Delphi-Quellcode:

while i <=6 do

Das erstellte mir im Stringggrid 7 'Wochenblöcke':

Anhang 53230

Wenn ich das <= durch < ersetzte, erhalte ich statt 7 "Wochenblöcke" noch deren vier, und der 31. januar wird mit den folgenden Wochen verscluckt.

Den Ausdruck '<=6' durch '<=5' zu ersetzen, ist auch keine Lösung - das würde wohl manche überzählige Woche nicht darstellen - ausser im Februar. Wie verlässlich-korrekt die Darstelllung sonstwo ist, hängt wohl von den entsprechenden Wochen ab.

Wie erreiche ich am zuverlässigsten, dass die Woche, in welche der Monatsletzte fällt, ausgegeben wird, aber dann wirklich Schluss ist?

Gruss
Delbor

[Klaus01]

Datum = 03.01.10000 ist das so gewollt?

Grüße
Klaus

[Aviator]

Ich vermute mal nicht. Und falls doch, dann muss könnte ich mir vorstellen, dass die Einschränkung von

Delphi-Quellcode:

DaysInAMonth

da der Verursacher ist. Habe gerade kein Delphi zur Hand um mich durch die Sourcen zu wühlen. Aber die genannte Funktion kann bspw. nur mit Jahren bis 9999 umgehen.

Zitat:

Zitat von DocWiki

AYear is a year from 1 through 9999 (inclusive).

[Delbor]

Hi Klaus01

Nein - ich wusste gar nicht, dass ein solcher Wert in einen TDateTime-Wert passt. Die Ursache ist das kleine Symbol '<='. Offenbar fängt "er" dann wieder zu zählen an; im Code geschieht dies immer mit 'Datum :=Datum + 1' Nachdem der/ein Monatsende erreicht ist, fängt der Datumsvergleich wieder von vorne an - und dies eben so lange, wie der Datenyp das Datum noch darstellen kann.


Gruss
Delbor

Ps: Ja, Aviator, jetzt, wo du's sagst: Ich hab das auch gelesen

[himitsu]

Diese Schleife ist meistens "endlos".

DayOfTheMonth (1-31) ist bei 50% der Monate immer kleiner als als DaysInTheMonth+1 (32) des Start-Monats und somit gibt es keinen Abbruch und läuft ewig.
Februar als Start ist das Einzige, wo es immer zum Ende des nachfolgenden Monats abbrechen wird.

endlos/ewig ... OK, zumindestens so lange wie das Datum gültig ist, also nach dem 31.12.9999 knallt es dann doch.

Im Debugger hätte dir aber schnell auffallen sollen, dass diese Schleife zu viele Durchläufe hat ... spätestens als es nach etwa 416376 Runden dann knallte.



Vielleicht solltest du für deine Schleifen das Ende eher mit EndOfAMonth/EndOfTheMonth bzw. EndOfAWeek/EndOfTheWeek und IncMonth bzw. IncWeek bestimmen.
Und den Anfang mit StartOfAMonth/StartOfTheMonth bzw. StartOfAWeek/StartOfTheWeek.

[Redeemer]

Zitat:

Zitat von Delbor (Beitrag 1476722)

Hi Klaus01

Nein - ich wusste gar nicht, dass ein solcher Wert in einen TDateTime-Wert passt.

In ein Double passt sehr viel rein, die Genauigkeit nimmt aber ab, je weiter du vom minus-ersten Januar des Normaljahres 1900 um 0 Uhr entfernt bist. Der letzte Tag, den TDateTime sekundengenau darstellen kann, ist der 12. November 188149436. Der letzte Wert ist in ca. 5*10^305 Jahren, also eine Jahreszahl mit 306 Stellen.

Die allermeisten Programme beschränken die Gültigkeit künstlich auf die Jahre 1 bis 9999. Excel kann hingegen nicht auf einen geringeren Wert als den 0. Januar des Schaltjahres 1900 (was kein Schaltjahr war) rechnen.