TPlannerDatePicker / Null Datum nicht zu fassen

[NicoleWagner]

Gegeben ist ein Formular mit einem TPlannerDatePicker.
Ein TPlannerDatePicker ist sehr ähnlich dem TDateTimePicker von Delphi und stammt aus der TMS-Komponentensammlung.

Meine Programmier-VM läuft auf Windows 7.
Das Programm läuft wunderbar in der Entwicklungs-VM und auch auf einer Win 10 Maschine.

Bis auf eine Ausnahme:
MANCHMAL wird unter Win 10 (2004) aus dem TPlannerDatePicker ein leeres Datum weitergegeben.
Unter welchen Umständen das passiert, vermag ich nicht zu sagen. Egal, ob ich das Datum ins Feld hineintippe oder mit dem Kalender wähle, es wird ein Null-Datum übergeben.

Ü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.

Hilfe! Wie fange ich den Fisch?
Danke für Hinweise.

[Sherlock]

Versuche doch mal Dein Glück mit Remote Debugging. Du musst eigentlich nur den PAServer auf der Windows10 Kiste installieren, und dich dann damit von Deinem Windows 7 verbinden.

Nebenbemerkung: Komische Konstellation übrigens. Ich hätte ja Win7 als Testsystem und Win10 als Entwicklungsrechner... mit der Aussicht Win7 sehr bald löschen zu können.

Sherlock

[NicoleWagner]

Danke für Deine Antwort. Als letzte Möglichkeit würde ich das probieren. Denn ich frage mich, ob ich nach der Arbeit, das einzurichten nicht auch in der IDE lesen würde "ach, da ist gar nichts", sobald ich remote ausführe.
Mit anderen Worten: Ich fürchte den Aufwand und auch, damit nichts zu finden.

Hast Du vielleicht eine Idee, wo die Information verloren gegangen sein könnte?
Das ist doch lähmend, dass vor meiner Nase das Datum steht und dann nicht ankommt in seiner Verarbeitung.

Weißt Du, was intern passiert bei so einem TDateTimePicker? Der sollte ja direkt mit Windows-Elementen interagieren.

[Uwe Raabe]

Ein

Delphi-Quellcode:

TDateTimePicker

ist ein natives Windows Control, der

Delphi-Quellcode:

TPlannerDatePicker

ist aber ein komplett anders implementiertes Control von TMS. Ich glaube kaum, dass das beschriebene Verhalten auf eine Gemeinsamkeit zurückzuführen ist.

Kannst du das Problem denn mit einem

Delphi-Quellcode:

TDateTimePicker

reproduzieren?

[NicoleWagner]

Danke für Deine Antwort.
War damals von Dir der geniale Hinweis, dass dieser TMS-Picker eine "isValid"-Funktion hat? Darum möchte ich ihn nicht gerne austauschen. Die ist nämlich extrem nützlich.

Dummerweise kann ich nicht genau feststellen, wo der Fehler passiert. Das Datum wird mir angezeigt, wie gewünscht, durchläuft die Prüfschleifen und erst die Bestätigungsmeldung enthält dann den "1.1.1899" (oder so ähnlich) statt etwa "18.8.2020". Die Verarbeitung passiert mit dem falschen Datum. Wie gesagt, nur in Win 10, nicht in Win 7. :coder2:
und worse: Der Fehler tritt in Win 10 auch nur manchmal auf, manchmal nicht.

[Uwe Raabe]

Zitat:

Zitat von NicoleWagner (Beitrag 1472018)

Darum möchte ich ihn nicht gerne austauschen. Die ist nämlich extrem nützlich.

Es geht auch gar nicht ums Austauschen, sondern um eine Überprüfung, ob es an der Komponente oder an Windows oder sonstwas liegt.

[NicoleWagner]

Ich glaube, es liegt am Zugriff und der Verarbeitung des Datumsfeldes.
Genau in dieser TMS-Komponente (ob ich den Fehler dort nicht höchstpersönlich verursache, ist die zweite Frage).

Ich rufe das Formular zur Termineingabe ua. auf mit:

TerminNeu(Datum_aus_Kalender_angeklickt);
oder
TerminNeu(0); // wenn eben KEIN Termin im Kalender (TMonthView) gewählt ist.

Mit der Null dachte ich, sollte das Datumsfeld leer bleiben und den Nutzer animieren, ein Datum einzugeben.
Doch Null-Fehler / Null-Parameter, Datum als '30.12.1899'.... vielleicht liegt es dort.

Ich ersetzte daher
TerminNeu(0);

durch

TerminNeu(trunc(now));
Damit wird mir jedenfalls das heutige Datum ins Feld geschrieben, statt dass es leer bleibt.

Wie gesagt, "leer" war es nicht, als ich den speicher-Befehl schickte, denn entweder hatte ich manuell ein Datum eingegeben oder eines
mit dem Kalender gewählt. Optisch sieht es identisch aus wie zuvor. Intern ist jetzt jedoch DAVOR ein anderer Paramenter übergeben.

Wie gesagt, ist es ein "manchmal, manchmal nicht" -Fehler.
Jetzt warte ich einmal ein paar Tage oder Wochen, bis es wieder kommt oder eben nicht.
Vielleicht ist dann auch "now" statt des Wunschdatums. Wer weiß.

[Uwe Raabe]

Zitat:

Zitat von NicoleWagner (Beitrag 1472036)

Doch Null-Fehler / Null-Parameter, Datum als '30.12.1899'.... vielleicht liegt es dort.

Liegt vielleicht daran, dass der Wert 0 als TDateTime dem 30.12.1899 entspricht. Ältere Daten werden durch negative Werte dargestellt.

[scrat1979]

Der TDateTime-Wert 0 entspricht im Datumsteil dem 30.12.1899, daher steht der Picker korrekterweise dann auf diesem Datum.

[himitsu]

Bei DevExpress mit den Datumskomponenten was Ähnliches.

Warum genau dieser Wert, kann ich nicht mehr sagen.
Ich glaub im DefExpress gab es auch irgendwo so eine Konstante.

Delphi-Quellcode:

const

  // Datumswerte vor/bis zum 01.01.1910 sind ungültig. (TcxDateEdit.Date und TCimDateEdit.Date)
  // Größer als 0, um z.B. auch AsDate+30 abzufangen
  // cxDateUtils.NullDate=-700000 (00.00.0000) / cxDateUtils.InvalidDate=-699999 / 0=30.12.1899 (und NULL)
  MyValidDate           = 3654;

Alle Werte kleiner als 10 Jahre nach 0 gelten ungültig.
0 war der größte gemeinsame ungültige Wert, im System.

"Bissl" über 0, damit auch Werte gefiltert werden, welche z.B. mit einem Offset gefüllt wurden. (paar Tage bis Jahre ... z.B. zeige mir die nächsten 3 Jahre an, ausgelesen aus der Datenbank)

Delphi-Quellcode:

DateEdit.Date := Field.AsDataTime + Irgendwas;

[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.

[QuickAndDirty]

Zitat:

Zitat von Delphi.Narium (Beitrag 1472106)

Verblüffende bis erschreckende Erkenntnis.

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

Das ist TMS!

[Rolf Frei]

Zitat:

Zitat von NicoleWagner (Beitrag 1472121)

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.

Ein grosser Fehler bei vielen Leuten ist nähmlich, dass man meint, die Windows Format Settings entspreche den Delphi Formatregel. Das ist NICHT so und so dürfen die Systemsettingsformate eben nicht in Funktionen wie FormatDateTime verwendet werden! Diese Funktion hat andere Formatregeln (siehe Delphi Hilfe). Insbesondere das "m" Zeichen gilt in Delphi für den Monat und das "n" muss für die Minuten verwendet werden. Windows behandelt das kommlett anderst. Ausserdem sollte man da beim Format immer die ANSI Notation nutzen, da es sonst zu fehlerhaften Datumskonvertierungen kommt, wenn das System andere Einstellungen hat.

Delphi-Quellcode:

// Falsch:
FormatDateTime('dd.mm.yyyy hh:nn:ss', Now)) 

// Richtig (nur so wird das Systemtdatumsrennzeichen verwendet):
FormatDateTime('dd/mm/yyyy hh:nn:ss', Now)) 

// Will man immer das Systemdatum nutzen reicht ein s:=DateTimeToStr(Now) und d:=StrToDateTime(s), das dann das Datum im Windows Format ausgibt oder zurückverwandelt. FormatDateTime ist eigentlich nur dazu da, wenn man vom Systemstandard abweichen will.

Der falsche Code führt bei folgendem Code in einer Englischen Windows Region zu einem Datumskonvertierungsfehler:

Delphi-Quellcode:

// Das Datum wird hier mit einem "fixen" Punkt als Trennzeichen geformt, also nicht mit dem Systemtrennzeichen. Es ergibt also immer ein Datum mit Punkt, was mit der USA Windows Region falsch wäre.
s := FormatDateTime('dd.mm.yyyy hh:nn:ss', Now)) 

// Wenn auf dem System nicht der Punkt das Datumstrennzeichen ist, sondern z.B. "/", führt dieser Aufruf zu einem Konvertierungsfehler!
d := StrToDateTime(s);

Eventuel ist genau das dein Prolbem, dass du da irgenwo FormatDatTime nutzt, das ein falsches Format angeben hat (Punkt anstatt "/").

[philipp.hofmann]

Zitat:

zum Thema TMS

Also ich habe mit TMS in Summe nur gute Erfahrung gemacht, sie brauchen nur sehr häufig ein kleines Demo-Projekt, aber dies kann man ja nachvollziehen.

Wenn du keinen Support hast, bekommst du doch eh keine Updates und dann ist deine eigene Fehlerbehebung im Code doch ausreichend. Nur wenn du die Updates bekommst, ist dir doch wichtig, dass deine Fehlerbehebung wieder drinnen ist. Wenn alle die mit Software verdienen, alle Fehlerbehebungen langfristig gratis verteilen, dann müsste der initiale Preis höher sein und alle Nutzer sind davon abhängig, dass es neue Nutzer gibt, die den initialen Preis bezahlen, da es sonst für den Hersteller uninteressant wird. Daher sind faire Supportverträge aus meiner Sicht eine sinnvolle Lösung.

Ich persönlich habe den Support bei TMS, weil die v.a. auch sehr schnell antworten, wenn man mal ein Problem hat. Das macht sich bezahlt.

[NicoleWagner]

Ich habe keinen Support mehr bei TMS.
Von denen selbst bin ich begeistet. Da ich jedoch nur für den Eigenbedarf programmiere, bekam ich damals nicht nur einen Sonderpreis, sondern die Aufzahlung für Support ist für mich persönlich unwirtschaftlich.
Wäre ich kommerzielle Programmiererin würde ich ihn mir jedenfalls leisten. In der ersten Zeit nach dem Kauf hatte ich Support und der war vom Feinsten. Forumszugang bei TMS habe ich leider auch keinen mehr. Ich darf nur lesen, nicht posten.

und: Die Null ist zurück, :(
Auch dort, wo ich "now" mit DateToStr reingeschoben habe.
Beim nächsten Versuch: alles in Ordnung, Datum wird korrekt übernommen.

Greife jetzt einmal auf Zwischenergebnisse zu. Eine Ausgabe mit ShowMessage vor StrToDate. Vielleicht werde ich dann schlauer.

Ich bin nur dankbar, dass ich auf die Idee kam, mir den Eintrag überhaupt im Volltext bestätigen zu lassen. Sonst hätte ich alle Einträge seither ans Null-Datum verloren, ohne es überhaupt zu bemerken.

[Jumpy]

Ist das denn mit den Datumsen reproduzierbar? Kannst du mal Beispiele nennem was geht und was nicht?

[Sherlock]

Ganz ehrlich, der Remotedebugger ist keine fortgeschrittene Magie.

Sherlock