Datumskontrolle !

Jagg · Beiträge: 635

Hallo !

Ich habe ein Editfeld,wo ich das Datum (Tag,Monat und Jahr) eingebe
Wenn ich dann auf Enter drücke,soll er überprüfen ob die Zahlen in dem EditFeld für ein Datum richtig sind !
Wie stelle ich das an ???

Jagg !

PS : Muss ich das mit Copy() machen und die einzelnen Zahlen rausfiltern ?

LCS · Verfasst: Mi 18.12.02 09:29

Hi
auch wenn jetzt vielleicht einige anderer Meinung sind, wäre der einfachste Weg zu versuchen, den String in ein Datum zu konvertieren, und wenn das eine Exception auslöst, weisst du das es ein ungültiges Datum war.

Gruss Lothar

_________________
Der BH ist für die Brust, der Plan ist für'n Ar...

Jagg · Beiträge: 635

in etwa so :

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

procedure TForm21.Edit7KeyPress(Sender: TObject; var Key: Char);
 var Date : TDate;
begin
  if Key = #13 then
  begin
    Date := StrToDate(Edit7.Text);
    Self.Perform(WM_NEXTDLGCTL, 0, 0);
    key := #0;
  end;
  if not (key in ['0'..'9',#8,#46]) then
    key:=#0;
end;

... ???

smiegel · Verfasst: Mi 18.12.02 09:34

Hallo,

wenn es schnell gehen soll:

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

TForm1.DatumEditKeyPress(Sender: TObject; var Key: Char);
var aDatum:TDateTime;
begin
  // Entertaste gedrückt
  if (key=#13) then
  begin
    try
      aDatum:=StrToDate(DatumEdit.Text);
    except
      on EConvertError do
      begin
        MessageDlg('Fehlerhaftes Datum!', mtError, [mbOk], 0);
        Key:=#0;
      end; // on
    end; // try
  end; // if
end; // TForm1.DatumEditKeyPress

_________________
Gruß Smiegel
Ich weiß, daß ich nichts weiß, aber ich weiß mehr als die, die nicht wissen, daß sie nichts wissen. (Sokrates)

Klabautermann · Verfasst: Mi 18.12.02 11:18

Hallo,

warum verwendest du kein tDateTimePicker?
Da kann kein falsches Datum eingegeben werden.

Gruß
Klabautermann

Wolff68 · Beiträge: 302 Erhaltene Danke: 1 WinXP home D6 Prof

LCS hat folgendes geschrieben:

auch wenn jetzt vielleicht einige anderer Meinung sind

Das wurde hier auch schon diskutiert.
Generell sollte man keine try-except Blöcke für vorhersehbare Fehler verwenden. Auch wenn einem das manchmal am einfachsten vorkommt.
Das nervige daran ist, daß Du die Fehlermeldung beim Debugging trotzdem immer abbekommst.

Wenn man in der Hilfe ein bischen stöbert findet sich da direkt bei EncodeDate auch eine Funktion namens TryEncodeDate.
Und rate mal was die macht: Sie gibt Dir keine Exception, sondern ein false zurück wenn das Datum nicht gültig ist... :wink:

_________________
"Der Mensch ist nicht was er sich vorstellt oder wünscht zu sein, sondern das was andere in ihm sehen."

LCS · Verfasst: Do 19.12.02 08:06

Wolff68 hat folgendes geschrieben:

Das wurde hier auch schon diskutiert.

Deshalb schreib ich's ja :wink:

Wolff68 hat folgendes geschrieben:

Generell sollte man keine try-except Blöcke für vorhersehbare Fehler verwenden. Auch wenn einem das manchmal am einfachsten vorkommt.
Das nervige daran ist, daß Du die Fehlermeldung beim Debugging trotzdem immer abbekommst.

Nur solange bis man's abschaltet.

Wolff68 hat folgendes geschrieben:

Wenn man in der Hilfe ein bischen stöbert findet sich da direkt bei EncodeDate auch eine Funktion namens TryEncodeDate.
Und rate mal was die macht: Sie gibt Dir keine Exception, sondern ein false zurück wenn das Datum nicht gültig ist... :wink:

Ja, für den Fall gibt's ne andere Lösung. Aber für tausend andere nicht. :wink:

Gruss Lothar

_________________
Der BH ist für die Brust, der Plan ist für'n Ar...

Klabautermann · Verfasst: Do 19.12.02 09:51

Hallo,

LCS hat folgendes geschrieben:

Ja, für den Fall gibt's ne andere Lösung. Aber für tausend andere nicht. :wink:

das halte ich für ein Gerücht. Wenn man sich die mühe macht, die Werte mit denen man Arbeitet genauer zu betrachten sollte sich so ziemlich jeder Fehler ohne Try Except abfangen. Die Frage ist nur denkt man vorher dran, das nacher dieser Fehler aftreten kann. Für den Fall, das man an eine möglichkeit nicht denkt, sollte man Try Except zusätzlich verwenden.

LCS hat folgendes geschrieben:

Nur solange bis man's abschaltet.

Das Problem ist aber, dass diese Meldungen in der Regel sehr Praktisch sind, um eigene Fehler zu entdecken, die man auf einfache Art behandeln kann, was dazu führen kann, das man bei speziellen Fehlern so geziehlt reagieren kann, das kein Fehler mehr auftritt. Denn durch pauschales einsetzen von TRY EXCEPT und dem darauf dolgenden Ignorieren der Fehler macht man sein Programm intollerang gegenüber dem User und macht das Arbeiten dadurch unangenehmer für ihn.

Gruß
Klabautermann

LCS · Verfasst: Do 19.12.02 10:51

Hi
was hab ich da nur angerichtet! :mrgreen:

Ich wollte diese Diskussion keinesfalls neu entfachen.

Klabautermann hat folgendes geschrieben:

Wenn man sich die mühe macht, die Werte mit denen man Arbeitet genauer zu betrachten sollte sich so ziemlich jeder Fehler ohne Try Except abfangen.

Das ist schon richtig. Aber ich denke wir sind uns auch einig wenn ich sage, dass gerade diese Fehlerbehandlungen einen Grossteil der Zeit beanspruchen. Deshalb tendiere ich dazu erst mal relativ simple Lösungen einzusetzen und sie eventuell später durch bessere zu ersetzen.

Klabautermann hat folgendes geschrieben:

Denn durch pauschales einsetzen von TRY EXCEPT und dem darauf dolgenden Ignorieren der Fehler macht man sein Programm intollerang gegenüber dem User und macht das Arbeiten dadurch unangenehmer für ihn.

Ich plädiere keineswegs für ein pauschales Einsetzen von TRY EXCEPT und schon gar nicht das Ignorieren von Fehlern. Programme, die sich bei Fehleingaben sang- und klanglos verabschieden gibts wie genügend. Aber meine User waren bis jetzt immer recht zufrieden. :wink:

Gruss Lothar

_________________
Der BH ist für die Brust, der Plan ist für'n Ar...

Wolff68 · Beiträge: 302 Erhaltene Danke: 1 WinXP home D6 Prof

Also ich bin auch kein Hardcore-Fehler-Abfanger und ich muß LCS beipflichten, daß es manchmal den Rahmen sprengen würde alle Eventualitäten selbst abzufangen. Try..Except gibt es, und dann darf man es auch verwenden.

ABER: Hier bei einem so trivialen Fehler auf Try-Except auszuweichen, ohne sich Gedanken zu machen, ob es auch was anderes gibt halte ich für fahrlässig.
Man sollte einfach erst mal überlegen, welche Möglichkeiten ohne Try..Except bestehen. Sind diese dann zu umständlich kann man immer noch darauf zurückgreifen.

_________________
"Der Mensch ist nicht was er sich vorstellt oder wünscht zu sein, sondern das was andere in ihm sehen."

Aya · Verfasst: Do 19.12.02 23:08

huhu,

also ich hab noch NIE Try/except verwendet... wenn man z.B. in nem EditFeld kein "," sondern nur "." eingeben können soll... dann lass ich sowas schon bei der eingabe garnicht zu..

und um nen Datum zu kontrollieren... würde ich schonmal 3 dinge bei der eingabe überprüfen...

1. Es dürfen NUR Zahlen und Punkte sein
2. Maximal 2 Punkte und 8 Zahlen
3. Vor jedem Punkt dürfen Maximal 2 Zahlen stehen

Wenn du das alles überprüfst, schon bei der eingabe... kann man fast schon kein falsches datum eingeben

Du könntest zudem noch prüfen bei der Eingabe ob die erste Zahl kleiner als 31 ist und die 2te kleiner als 12..

Au'revoir,
Aya~

LCS · Verfasst: Fr 20.12.02 09:40

Hi Aya
und was machst du wenn der User sein Datum im ISO-Format eingibt: 2002-12-20 :wink:

Dann gehst du entweder her und zwingst den User zu einem bestimmten Datumsformat, oder du schreibst ellenlange Fehlerabfangroutinen. Und genau sowas meine ich: Lösung 1 ist völlig inakzeptabel, weil dein Programm dadurch einfach unflexibel wird, und Lösung 2 ist mir während der ersten Entwicklungsphase zu zeitaufwändig.

Gruss Lothar

_________________
Der BH ist für die Brust, der Plan ist für'n Ar...

Aya · Verfasst: Fr 20.12.02 13:47

Hi,

ich benutze als Datums Format das, was in den Ländereinstellungen vom Windows eingestellt ist... daran hat der User sich zu halten

Au'revoir,
Aya~~

PS: Wenn man das aktuelle datum eingeben soll, würde ich das schon von vornherein in das Feld eintragen

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme