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 TDateTimePicker ist ein natives Windows Control, der 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 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.
und worse: Der Fehler tritt in Win 10 auch nur manchmal auf, manchmal nicht.

[Uwe Raabe]

Zitat von NicoleWagner:

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.

[Jumpy]

Zitat von NicoleWagner:

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