Hi,

I have a script with a custom dialog where a user can enter a date. The field used for this is a global date field gdate.

I have a loop in the script to validate the date entered into the custom dialog box but cannot get it to validate properly.

Basically I want to stop people entering incorrectly formatted dates and/or typos i.e 1/1/117 or 1 July 2001

I have tried to get the date to be between a range (both using the getasdate and without):

Exit Loop If[gDate > GetAsDate(01/01/2006) and gDate < GetAsDate(01/01/2020)]

I have also added:

IsValid(gDate) = 1

To no avail :

NOTE: There is a lot more to this script (i.e the date cannot exceed two different calculated dates on two different instances) so it's a bit more convoluted than just using validate BillDate field, but wasn't sure how to change the calc so if the user is in a particular privilege set it does not apply.

See the attached for the example of convoluted.

TIA

date.zip

First script-step after your comment about "This is where I need it to validate" ...

Exit Loop If [ IsValid ( date::gDate ]

... you suggested IsValid(gDate) = 1. But IsValid(gDate) already returns a boolean result of true or false (1 or 0). By asking If ( IsValid ( Date::gDate) , if it is valid it returns 1 (true) and exits the loop and goes to the next test, saying that the date is a valid date and then the next test can take over and make sure it is within the range you wish.

:wink2:

BTW, I'm a bit too tired to go through your script tonight but I would suggest that most of the If[] tests can be handled within one test, by using a Set Field[] Case() calculation to 1) set the BillDate and 2) provide one single custom dialog again depending upon a Case() calculation.

If you still would like help refining your script tomorrow evening (and if others haven't assisted), I'll be happy to help. Also, I would suggest that you always heavily comment your scripts. Between each If[] test, list your logic. You will be glad you did when you need to review it later. It will also make it easier to reverse-engineer if another developer needs to review it (like now).

:wink2:

That would be great thanks. I'd like to code it as concise as possible.

isvalid however doesn't recognise 01/01/117 as invalid, rather a very early date! So I need to add the > and < to fix it.

Yeah, I normally comment but since I'm in-house it's my way of keeping other people befuddled about how it all works... thus job security haha.

You need to do a couple of things:

check the date is valid (this sorts our leap years etc)

check the date is within an acceptable range.

Exit Loop If [

not isempty( gdate ) and

isvalid( gdate ) and

gdate > date( 1 ; 1 ; 2006 ) and

gdate < date ( 1 ; 1 ; 2020 )

Use the Date() function instead of GetAsDate() because GetAsDate() is dependent on the operating system localisation:

GetAsDate( "3/4/2008" ) returns 4 March 2008 in USA but 3 April 2008 for Australians.

The Date() function has no such ambiguity.

And GetAsDate (01/01/2006) returns an error anywhere on the planet - because it performs a division first, then tries to convert .0004985044865404 (i.e. zero) into a date.

Yes indeed... in my example above I had the date as literal text: GetAsDate( "3/4/2008" )

Yes, you had - but OP had not.