TPlannerDatePicker / Null Datum nicht zu fassen

[NicoleWagner]

Uwe (und die anderen). Ja, darum veränderte ich es ja von Null aus now.

Unklar bleibt jedoch, warum die Null ÜBERGEBEN wird, obwohl die Komponente sichtbar ein anderes Datum EINGETRAGEN hat. (Zur Erinnerung: Mit dem Debugger kann ich auf die Werte zur Laufzeit nicht zugreifen, weil der Fehler nur in einer anderen Umgebung auftritt.)

So sieht die Prüfung / Ausgabe aus:

var s, s1, ausgabe: string;
datum: TDateTime;
SL: TStringList;
i: integer;
d: double;

....
d:=PlannerDatePicker_Termine.date; // Zugriff auf das Datum in der Komponente
if d=0 then begin
ShowMessage('bitte ein (gültiges) Datum eingeben');
exit;
end;

If not self.PlannerDatePicker_Termine.IsDateValid then begin
ShowMessage('Datum im DatePicker ist fehlerhaft');
exit;
end;

datum:=PlannerDatePicker_Termine.date; // datum wird zugewiesen

if RadioGroup_TerminNeu.ItemIndex=1 then begin
s1:=DateToStr(datum) + ' ';
.....
......
ausgabe:='Finanz: "' + s1 + ' ' + s + '" wurde gesichert in ' + Finanzdatei;// => hier sehe ich (manchmal!) das Datum 1899
end;

[Jumpy]

Zitat:

Zitat von NicoleWagner (Beitrag 1471988)

Übernehme ich die Daten, die das verursachen, in die Windows 7 VM, wo ich es in Delphi debuggen könnte, - dann stimmt es wieder. Das Datum wird korrekt übernommen.

Was sind das denn für Daten? Könnte das ein Lokalisierungs-Problem sein? Hat die Komponente einen internen Validator, der lieber 0 zurückgibt statt einer fehlermeldung?

[philipp.hofmann]

Ich habe dies mit den TMS-Komponenten und dem Datum folgendermaßen gelöst:

Initialisierung:

Delphi-Quellcode:

  eBookingDate.Text:=DateToStr(Now);//-> wichtig: eBookingDate.Date:=NOW ist laut TMSSoftware nicht möglich, da dies Lokalisierungsprobleme verursacht;
  eBookingDate.Text:='';            //eBooking.Date entspricht weiterhin NOW, was oft besser passt, wenn das PickUp aufgerufen wird

Abfrage:

Delphi-Quellcode:

  bookingFilter:=0;
  if (length(eBookingDate.Text)>0) then
    bookingFilter:=eBookingDate.Date;

[NicoleWagner]

danke Philipp: das klingt nach ganz heißer Spur.
Doch ich stehe auf der Leitung: Was sind "Lokalisierungsprobleme"?

PS zu oben: Das mit "now" hat nicht funktioniert, das Datum mit Null geistert nach wie vor durch meine App.
Das klingt ähnlich wie Dein Satz oben zur Zuweisung, den ich leider noch nicht verstanden habe.
Vielleicht kann ich die Geister vertreibe, sobald ich Deine Antwort verstanden habe.

und: Gibt es eine Doku, wo ich diese Hilfe-Sachen nachlesen kann?
Ich nutze ein pdf auf englisch, das ich auf der TMS-Seite fand. Leider ist es schon ein paar Jahre her, seitdem ich mir die Komponente zulegte. Habe also weder die aktuelle TMS-Version, noch aktuelle Hilfe.

[Delphi.Narium]

Lokalisierungsprobleme heißt:

Statt 19.08.2020 z. B. 08/19/2020 oder 2020.08.19

Irgendeine Systemeinstellung für u. a. die Datumsdarstellung wird / ist (sporadisch?) "verstrubbelt".

Eventuell kannst Du ja dann, wenn das Datum mal wieder 0 wird, die entsprechenden Systemeinstellungen auslesen und mal in 'ne Textdatei schreiben, um sie Dir zu Gemüte zu führen.

Oder Du setzt Dir beim Programmstart grundsätzlich Datums- und Zeitformat so, wie Du es im Programm erwartest.

In etwa sowas:

Delphi-Quellcode:

// Irgendwo im Formular ...
  private
    { Private-Deklarationen }
    fFormatSettings: TFormatSettings;

// z. B. im FormCreate:
  GetLocaleFormatSettings(LOCALE_SYSTEM_DEFAULT, fFormatSettings);
// Jenachdem, wie Du es brauchst / erwartest.
  fFormatSettings.LongDateFormat  := 'DD.MM.YYYY';
  fFormatSettings.LongTimeFormat  := 'hh:mm:ss.zzz';
  fFormatSettings.ShortDateFormat := 'DD.MM.YYYY';
  fFormatSettings.ShortTimeFormat := 'hh:mm:ss.zzz';

Wenn nun (sprodisch) eine andere Software (oder der Anwender) mal die Systemeinstellungen für's Datum ändert, wirkt sich das nicht (zwingend) auf Dein Programm aus.
Ob's damit aber wirklich funktioniert, vermag ich nicht zu sagen. Aber 'nen Versuch ist es ja vielleicht wert.

[haentschman]

Hinweis:
Das Zeitformat ist nicht immer richtig. :roll: ...oder ist das inzwischen korrigiert? :gruebel:
https://www.delphipraxis.net/188843-...s-dummies.html

[philipp.hofmann]

Zitat:

Oder Du setzt Dir beim Programmstart grundsätzlich Datums- und Zeitformat so, wie Du es im Programm erwartest.

Und genau dies darf man laut TMSSoftware bei ihrem DatePicker nicht machen, sondern setzt immer das Datum über das Default-Format des Betriebssystemes, daher

Delphi-Quellcode:

  eBookingDate.Text:=DateToStr(Now);

und nicht

Delphi-Quellcode:

  eBookingDate.Text:=DateToStr(Now,fFormatSettings);

Klingt komisch, is´aber so.

Und wenn man

Delphi-Quellcode:

  eBookingDate.date:=NOW;

ausprobiert, wird es je nach Betriebssystem-Einstellung krachen oder funktionieren (obwohl man eigentlich denken würde, hier spiele die Betriebssystem-Einstellung gar keine Rolle, aber auch hier gilt der Sendung-mit-der-Maus-Spruch uneingeschränkt (wobei der Spruch Gerüchten zufolge von Peter Lustig erfunden wurde).

[Delphi.Narium]

Verblüffende bis erschreckende Erkenntnis.

Aber wenn's bei TMS so ist, dann ist das so. Bug oder Feature?

[philipp.hofmann]

Ich persönlich würde es als Bug einordnen und habe den Vorschlag gemacht, dann zumindest das date-Attribut auf ReadOnly zu setzen. Aber macht es auch nur bedingt schöner, weil man das text-Attribut ja auch nur auf bestimmte Art und Weise setzen darf. Richtig sauber wäre es nur, wenn man der Komponente ein FormatSettings spendiert.

[NicoleWagner]

Ganz lieben Dank vor allem an Philipp, doch auch an alle anderen.
Das sind wirklich ganz neue Einsichten.

Ich habe jetzt die Pervers-Lösung mit DateToStr / StrToDate implementiert.
Meine ersten Versuche waren "Nicht-Null".
Die nächsten Tage und Einträge werden zeigen, ob das so bleibt.