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.

[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 von NicoleWagner:

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)
DateEdit.Date := Field.AsDataTime + Irgendwas;