| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 265.1 | Try CAL$SET_DATE for different results | BUFFER::VICKERS | Winners take action not keep score | Tue Mar 17 1992 21:23 | 13 |
| CAL$CHECK_DATE seems to have the same 'interesting' behaviour in V3.0.
I am pretty sure that this behavior was discussed in the previous
conference and was put off to 'creative' parsing.
A more usual and powerful way to validate dates is to do what the TM
subsystem does. It uses the CAL$SET_DATE DSAB which allows for date
computation within the field in the form of TODAY + 1M and so forth.
It does have the side effect of setting the current calendar date but
this can be overcome by saving and restoring it on either side of the
field.
Have fun,
don
|
| 265.2 | I can name that tune in !AS notes | HYTIDE::CREAMER | Keep a low profile | Tue Mar 17 1992 21:46 | 24 |
|
Sean,
Don's method will, of course, work quite well. You could do it
from within Named Data by:
;;DATE_FIELD;;
/VALID=<GET #SAVED_DATE=OA$TM_DATE\CALENDAR SET DATE DATE_FIELD
\.IF OA$STATUS EQS '1' THEN GET DATE_FIELD = OA$TM_DATE\\OA$VAL_SET_VALID
ELSE GET OA$DISPLAY OA$_IFR\CALENDAR SET DATE #SAVED_DATE
Another method might be to use the DATE_CONVERT function.
;;DATE_FIELD;;
/VALID=<DATE_CONVERT #FOO,DATE_FIELD,2\.IF #FOO EQS "" THEN
GET OA$DISPLAY = OA$_IFR ELSE GET DATE_FIELD = #FOO\\OA$VAL_SET_VALID
HTH,
Jack
|
| 265.3 | contrarian name | SHALOT::LAMPSON | Whatever ya do, ya gotta have FUN! | Tue Mar 17 1992 22:33 | 6 |
| Actually, contrary to CAL$SET_DATE's name, it does NOT set the TM
calendar date.
Cheers,
_Mike
|
| 265.4 | Okay, I'm stupid but so are the docs (on this one) | BUFFER::VICKERS | Winners take action not keep score | Wed Mar 18 1992 02:12 | 17 |
| It would be really nice if the documentation (including V3.0) would NOT
state that CAL$SET_DATE sets the date for the calendar. The statement
in the documentation was the reason that I went ahead and included my
statement about the DSAB setting the date.
My experiences with using this DSAB has been that it doesn't SEEM to
change the date which confirms what Mike says in .3. However, it has
also SEEMED that I have seen the TM date change (apparently) strangely
where I have used this DSAB. Given my programming 'techniques' it
could be that I have done something stupid elsewhere to cause this
'feature'.
I normally am quite good at making myself look stupid all by myself but
it appears that the documentation gave me an 'assist' on this one.
The important thing always is to help customers,
don
|
| 265.5 | CAL$SET$CHECK$OA$DATE: | BRUMMY::MARTIN::BELL | Martin Bell, TCC, Birmingham UK | Wed Mar 18 1992 15:06 | 23 |
| I am also very interested in date and time validation within ALL-IN-1.
CAL$SET_DATE, as suggested by Don is great, but unfortunately it does not
understand time. Thus if you use it to validate fields held within an ENTRY
form using /language=NBS_DATE, for initial entry (eg "+w" or "TODAY") it is
very user friendly.
Unfortunately, when recalling the date, it returns including the TIME, which
causes OA$SET_DATE some problems.
Now CAL$CHECK_DATE does understand TIME, but also (as Se�n has spotted), it
also understands several other constructs which do not appear to apply to
this Earth (unless we are talking hexadecimal time onwards!).
Jack (.2) has a nice bit of date validation code, but WOULDN'T IT BE NICE if
standard ALL-IN-1 included date validation that was consistent - it understands
dates AND times AND shortcuts in all languages.
If ALL-IN-1 can't do it as standard, then maybe we need to develop the best
workaraound that gives the good points of all the current methods.
mb (under GMT)
|