CompareDate gibt immer 1 aus...

[Codix32]

Zitat:

Zitat von Popov (Beitrag 1302997)

Zitat:

Zitat von himitsu (Beitrag 1302993)

Zitat:

Warum?

Formatiere mal den Quelltext ordentlich und dann sieht du es bestimmt.

Wollte ich gerade auch drauf hinweisen.

......

Im Code

Delphi-Quellcode:

compareDate(vor,nach)

steht vor vor nach. In der Funktion

Delphi-Quellcode:

Zeitraum

ist in der Zeile

Delphi-Quellcode:

wievieltePackung(Tagedazwischen(dt, vorTag))

der vorTag an zweiter Stelle. Ich weiß nicht welche Tage in dt stehen, aber ich gehe davon aus, dass es nachTage sind. Vielleicht solltest du für den Fall in der Funktion Tagedazwischen zuerst vor und nach sortieren, also prüfen ob vor auch wirklich das frühere Datum ist. Ansonsten prüfst du drauf ob das spätere Datum vor dem älteren Datum steht. Das Ergebnis wäre in dem Fall -1.

Danke Popov,

Ein Ergebnis war falsch und deshalb habe ich die Funktion und es konnte nur die Funktion sein, im OnKeyDown Ereignis eines TEdits getestet und eben entdeckt, dass egal, was für ein Datum ich eingebe, ob größer oder kleiner als das 2. Datum immer eine 1 ausgegeben wird, auch wenn die beiden Datums gleich sind.

Hier der einfache Test über ein Editfeld:

Delphi-Quellcode:

procedure TForm1.Edit1KeyDown(Sender: TObject; var Key: Word;
  Shift: TShiftState);
var
  t:TDate;
begin
 if key = VK_Return then
   begin
    Try
     if Edit1.Text = '' then
        t := Date
     else
        t:= strtodate(edit1.Text);
     Zeitraum(t);
    Except
     Zeitraum(now);
    end;
   end;
end;

[Codix32]

Ups, ich glaube, ich habe Alzheimer, ich habe den Fehler.

Ich habe tatsächlich ein falsches Datum als festgelegten zweiten Parameter übergeben.
Das ist jetzt wirklich Höchstpeinlich :oops:
Egal, was ich eingegeben habe, das Datum war immer größer.

Ich bitte euch alle um Entschuldigung.

[himitsu]

Und bezüglich des

Delphi-Quellcode:

    Except
     Zeitraum(now);
    end;

Einfach so was "Anderes" machen, ohne dem Bediener seinen Fehler zu nennen, ist nicht die feine englische Art.

Und zusätzlich ist diese Art der Fehlerbehandlung eh "ungünstig", dazumal es sowieso absichtlich ein TryStrToDate oder StrToDateDef gibt, was man besser statt einer Exception verwenden sollte.

[Codix32]

Zitat:

Zitat von himitsu (Beitrag 1303002)

Und bezüglich des

Delphi-Quellcode:

    Except
     Zeitraum(now);
    end;

Einfach so was "Anderes" machen, ohne dem Bediener seinen Fehler zu nennen, ist nicht die feine englische Art.

Himitsu, was meinst Du mit "was Anderes"?

Zitat:

Zitat von himitsu (Beitrag 1303002)

Und zusätzlich ist diese Art der Fehlerbehandlung eh "ungünstig", dazumal es sowieso absichtlich ein TryStrToDate oder StrToDateDef gibt, was man besser statt einer Exception verwenden sollte.

Danke Himitsu, aber so gut bin ich nicht im Programmieren. Ich bewundere allerdings Deine Kenntnisse und habe großen Respekt. Und danke für den Tip. Allerdings hat Editkeydown genau das gemacht, was ich wollte.

Nochmals Allen vielen Dank :oops:

[himitsu]

Fehlerbehandlung sollte mit eine der ersten Dinge sein, die man unbedingt lernen sollte.

Einfach nur das verwendete StrToDate durch eine der beiden fehlerbehandelnden Funktionen austauschen und dafür das Try-Except weglassen.


Oder alles so lassen und blos das Try-Except weglassen. Dann bekommt der Bediener eine Fehlermeldung und der nachfolgende Code wird nur ausgeführt, wenn er die Eingabe richtig macht.
Sonst weiß er garnicht, daß das eingegebene Datum falsch ist und er wundert sich nur, warum dein Programm "Schrott" berechnet, also mit dem "falschen" Datum.



Debugge mal Programme, welche Code wie Diesen benutzen, was auch zu oft in Fremdkomponenten vor kommt.
Da wird man verrückt und will den Programmier davon nur noch erwürgen, weil das Programm so ständig sinnlos irgendwo hängen bleibt.

Delphi-Quellcode:

S := 'abc';
try
  i := StrToInt(S);
except
  i := 0;
end;
ShowMessage(IntToStr(i));

Richtiger wäre es so

Delphi-Quellcode:

S := 'abc';
i := StrToIntDef(S, 0);
ShowMessage(IntToStr(i));

oder

Delphi-Quellcode:

S := 'abc';
if TryStrToInt(S, i) then
  ShowMessage(IntToStr(i));

// oder
S := 'abc';
if not TryStrToInt(S, i) then
  raise Exception.CreateFmt('Was soll denn der Scheiß? "%s" ist doch kein Integer!', [S]);
ShowMessage(IntToStr(i));

Oder halt ganz einfach so und nur arbeiten, wenn in "S" etwas "Ordentliches" drin steht.

Delphi-Quellcode:

S := 'abc';
i := StrToInt(S);
ShowMessage(IntToStr(i));

Aber wenn man mit Exceptions arbeitet, dann grundsätzlich niemals irgendwelche Fehler, vorallem keine Eingabefehler, blindlinks abfangen oder gar durch Irgendwas ersetzen und den Fehler ungezeigt verwerfen.