I’m entering a variable in a TEO; the variable must be in a simple date form: ##/##/##. If I were entering a value in a date field, validating it would be simple. But is there a way to validate the variable?
Maybe this would work for you:
Set the TEO to use the text editor options for a date field that has an input pattern of
Add a procedure to your text editor, which is triggered when ending the editing, that will confirm a valid date was entered:
try
theVariable=datepattern(date(theVariable),"MM/DD/YY")
catch
nsnotify "Uh-oh! Bad Date."
theVariable=""
showvariables theVariable
endcatchCooperT - that’s a great catch.
billconable - understand that ambiguity of ##/##/##. Sometimes dates are presented as M-D-Y, sometimes as D-M-Y, or Y-M-D. So it would be handy if you put some static text above the field showing your required format. Of course, that’s no guarantee the user will enter it that way - you’ll still need to check it - but at least they’ll know what you want.
You’ve probably seen input fields that have the desired format preloaded - usually with a lighter shade font - that gets replaced when you enter your own date. It’s cute, but the format hint goes away as you enter data, and sometimes you might be interrupted or make a typo. Getting that per-loaded hint back might take some kind of refresh. So I like the “always there” example next to the field - assuming you have room for it on the form.
Indeed it is a great catch, and putting the input pattern in there takes care of typing mistakes like 4/3/23 and 4#3#23, both of which are beautifully corrected to 04/03/23.
@designer: I only used the #s for the purposes of this question; I was trying to cope with numb fingers typing in the wrong separator and was too bleary to write MM etc. instead of ##. Of course I have my prompt above the field in the correct form.
It’s a question of personal taste, but I would skip the input pattern. That way I would be allowed to enter natural dates like tuesday or may 12. But if you never want to do that, by all means use the input pattern.
One more “belt and suspenders” issue: just because a date is a valid date, that doesn’t assure it’s a reasonable date. If you have boundary parameters in mind - like the date entered shouldn’t be older than a year (month, days?), or a future date with an upper limit, you can test the entered date with respect to “Today()” as a reasonableness test.