Feld vom Typ Datum/Zeit

[Jürgen Schomann]

Ich habe eine Maske mit einem bearbeitbaren Feld vom Typ Datum/Zeit. Wenn ich als Stil Kalender-/Uhrzeit-Steuerelement einstelle werden fehlerhafte Datumsangaben vor der Rückgabe der Steuerung an das Anwenderprogramm oftmals automatisch in ein nächstliegendes Datum umgesetzt. Damit ist nicht mehr erkennbar ob die Angabe gewollt oder ungwollt ist. Was bei einer Verarbeitung auf Grundlage des Datums zu Problemen führen kann.
So wird z. B. die Angabe 14%&u zu 14.06.2009 umgewandelt wenn das aktuelle Datum ein Tag im Junit 2009 ist. Eine Angabe 14.08%&u wird zu 14.08.2009 umgesetzt wenn das aktuelle Datum im Jahr 2009 liegt. Andererseits wird z. B. 14.06.=o2009 als falsch erkannt und die Meldung 'Uhrzeit oder Datum kann nicht interpretiert werden' ausgegeben. 14.06.=z2009 aber nicht als falsch erkannt, sondern zu 14.06.2009 umgesetzt.
Wenn der Stil Notes für o. g. Feld gewählt wird, tritt diese Effekt nicht auf. Ich würde aber gern o. g. Stil wegen der Möglichkeit des Auswahl über den Datumswähler verwenden.
Gibt es eine Möglichkeit diese automatische Umsetzung zu verhindern und eine Validierung fehlerhafter Datumsangaben zu ermöglichen?

[Axel]

So eine automatische Umsetzungen habe ich bisher noch nicht beobachtet. Allerdings habe ich so "krumme" Werte noch nie in ein DAtumsfeld eingegeben.

Versuch's mal das über die Formel für die Eingabevalidierung abzufangen.

Axel

[Jürgen Schomann]

Das geht leider nicht, denn bevor überhaupt die Steuerung an das Anwenderprogramm zurückgegeben wird, erfolgt diese automatische Umsetzung bereits, so dass dann fast immer ein richtiger Datumswert erscheint.
Also weder Eingabeumsetzung noch Eingabevalidierung oder Ereignis Exiting greifen hier. Unter Notes 6 war es noch schlechter, dort wurde fasst jede unsinnige Zeichenfolge in ein Datum umgesetzt, z. B. auch das Zeichen ö.
Wie gesagt unter Notes 7 schon weniger. Aber eben nicht vollständig. Natürlich sind die genannten Beispiele provoziert, aber wie gesagt führt ein Tippfehler ggf. trotzdem zu einem richtigen Datum, wo dann nicht mehr erkennbar ist ob es so eingegeben wurde oder automatisch aus einer fehlerhaften Eingabe herrührt.
In meinem Fall möchte ich eigentlch in einer Dialogbox ein Datum eingeben lassen und dann wird diese Dialogbox schon mit OK verlassen. Wenn der Anwender nun nicht gründlich die Eingabe vorher noch einmal prüft und gleich OK drückt kommt meistens trotzdem ein nicht vorhersagbares Datum beim Anwenderprogramm an. Je nach dem was mit diesem Datum dann geschehen soll, kann es in der Folge zu ungewollten Reaktionen führen. Z. B. wenn das Datum die Grundlage für das Aufsuchen von Dokumenten, die zu löschen sind o. ä., bildet.

[koehlerbv]

Jürgen, vorab kann ich nicht bestätigen, dass sich ein Unterschied zwischen den Styles "Notes" und "Kalender-/Uhrzeit-Steuerelement" feststellen lässt. Zumindest nicht mit Deinen Beispielen.

Ich denke, Du bist hier auf ein "philosophisches" Problem gestossen: Welche Erleichterungen inklusive Korrektur möglicher Fehler soll eine Software automatisch korrigieren? Und in diesem Fall kommt noch hinzu: Was nimmt die Middleware auch noch dem Programmierer ab?
Besonders deutlich wird dies bei dem von Dir gewählten Style: Rechts steht das Steuerelement "Kalender" (für die Deppen, Tippfaulen, Zeitverschwender - und die, die wirklich gerade nicht wissen, ob der letzte Montag nun der 13. oder doch erst der 12. war. Das schreit ja nun regelrecht danach, den Rest "Erleichterung" auch noch zu bewerkstelligen.

Und wo ist nun der Unterschied zwischen der Eingabe von "12" (für den 12.07.2009 - was ich zum Beispiel sehr schätze) und 12.7.09 (ebenfalls für den 12.07.2009. was schon wieder fraglich ist - man könnte ja wirklich das Jahr der Schlacht im Teutoburger Wald meinen)?
Weiters: Schau Dir mal andere Produkte an - viele verhalten sich gleich oder zumindest sehr ähnlich. Ich habe mal ein paar Tests mit Deinen Beispielen mit der Fahrplanauskunft der DBAG im Web gemacht ...

Was man aber von IBM Lotus erbitten könnte: Ein Event "QueryRecalc". Das wäre wirklich manchmal nicht schlecht  Allerdings steht uns ja auch frei, ein Textfeld zu erstellen und daneben selbst ein Kalendersteuerfeld zu plazieren. Damit haben wir wieder die (fast) volle Kontrolle. Wenn Du es brauchst: Mach es doch.

Bernhard

[Jürgen Schomann]

Vielen Dank für deine Antwort.
Zu dem Unterschied Style Notes oder Kalender-Steuerelement ist richtig, dass das Verhalten gleich ist.
Übrigens läßt sich über QueryRecalc und das uidoc der echte Wert noch abfangen, danach erfolgt dann aber die Notes-Umsetzung. Man könnte dann sogar den Wert z. B. bei PostRecalc wieder so zurücksetzen. Bei einem Save wird aber Queryrecalc nicht durchlaufen und der Wert umgesetzt. Nur wenn man bei QuerySave selbst über uidoc.Refresh versucht Queryrecalc anzusteuern. Die Umsetzung aber auch schon geschehen. Wenn nun gleich ein Close folgt weiß man eigentlich nicht genau was im Dokument ankommt weil die Umsetzung und das Schließen des Dokuments so schnell erfolgen. In meinem Fall ist es wie gesagt das OK der Dialogbox und ich möchte gleich mit der Verarbeitung beginnen. Ich habe jetzt immer noch einmal das erhaltene Datum zur Bestätigung ausgegeben bevor ich es verarbeite.
Das mit einem Textfeld ist mir auch schon als Idee gekommen. Ich weiß bloß nicht wie ich dann trotzdem noch den Datumswähler verwenden könnte, der doch auch eine Hilfe darstellt. Der Datumswähler ist doch nur wieder mit dem Datum/Zeit-Feld verwendbar?