Validate Date, Time or Timestamp

[frinholp]

Hi all,

I would like to validate search criteria for a timestamp field before a find is performed.

My preference is that a date would be valid entered using the following formats:

d/m/yy

d/mm/yy

dd/m/yy

dd/mm/yy

d-m-yy

d-mm-yy

dd-m-yy

dd-mm-yy

(for all of the above yyyy would also be acceptable and either 01 or 1 would be acceptable for day

or month.)

also checking that day/month/year is valid in terms of days in a month, months in a year etc.

Time would be valid in 24hr clock format i.e 0015 or as 12hr format i.e 12:15am.

A full date and time would be valid if time follows date e.g 27/03/01 0015.

My intention is to write a custom function that would return a boolean dependant on whether a text entry meets certain criteria.

I was wondering if anybody aware of any custom functions that are freely available that could assist me in developing my own function? Maybe one that handles solely the date element or time element? Maybe there is one out there that meets the majority of my requirements (wishful thinking)?

Thinking further ahead, I would then need to convert the input (if valid), into a FM timestamp to use in the search.

Maybe there is a more efficient way to achieve my goal using native functionality?

Any pointers would be greatly appreciated.

Thanks in advance,

Lee

[comment]

Why not enter the criteria directly into a timestamp field? This would be validated by Filemaker itself, against the date & time formats being used for the file. You can also check for:

IsValid ( GetAsTimeStamp ( TextEntry ) )

[frinholp]

Thanks Comment

Does exactly what I would like.

As I am validating a field in find mode, what method would you suggest to allow operators? I don't mind coding this using substituting or pattern matching. Maybe you are aware of a native or custom function that already caters for this though?

Thanks again

Lee

[comment]

I suppose you could substitute out the operators (after checking by Filter() that no other characters are present). But I am still not sure why you need to do all this yourself.

[frinholp]

My requirement is to only allow valid search criteria for a certain field type to be entered in Find mode, and to display a custom dialog if invalid search criteria has been used for that field type.

Earlier in development I was asked to a display a custom dialog when validation fails on data entry. I was asked to do this to allow more options than the native 'OK' and 'Revert field' and also to display a more meaningful message in respect of which aspect the validation failed e.g separate message for out of range or invalid data for field type. I have scripted all my validation rather than using the native validate by calculation as to allow for extra options when a validation error dialog is displayed e.g a field has been entered fully in lowercase, throw a dialog with options to title case, keep the same or change.

Now the issue is consistency - all dialogs are to be be in a similar format to the previous, which rules out using the native dialogs.

If you could suggest a better method of achieving this by relying on the native validation a little more, as opposed to using my own functions and scripts, I would be very grateful. It is not a problem to backtrack if it will save a lot of pain in the long run.

This is the first time I have developed in Filemaker and I realise that I am not fully aware of the most efficient techniques in overcoming certain issues. It has been a steep learning curve.

At the moment I feel that I am often fighting Filemaker's native functionality, and scripting around it to customise to my requirements rather than working with it.

Thanks again

Lee

[comment]

If you could suggest a better method of achieving this by relying on the native validation

Well, it depends on how specific you want to get with your error messages and correction options. It's difficult to foresee every which way users can screw things up. You could have your script check meticulously that the entered year is in the range 1..4000, that the month is between 1..12 and that the day fits the month and year type etc., then notify the user of their exact error. OTOH, you could perform a blanket test for valid entry - or anything in between.

See the attached for something that could serve as a starting point.

PreValidateFind.zip

[frinholp]

Thanks for the demo file Comment

This approach allows me to achieve exactly what I require.

I forgot all about using the False parameter on Exit Script.

Lee

[frinholp]

Hi Comment

Digging up an old post here.

I was wondering if there was any way of using a similar method to the example file in browse mode. I have tried, but the code never gets executed. I have been informed that error may not get thrown until the validation has taken place.

An example would be to test for uniqueness of a field in browse mode.

Set a field to validate unique values only.

The following script attached to that field's OnObjectValidate script trigger enabled in browse mode.

Set Error Capture [On]



If [ Get (LastError) = 504 ]



Show Custom Dialog [ "My Dialog" ]



Exit Script [FALSE]



EndIf

Is there any method you can think of that would have a result similar to what I am trying to achieve in the above code snippet?

Thanks again

Lee

[comment]

There is no reason why the Set Error Capture [On] step would generate an error, so your script does nothing.

It's important to remember that OnObjectValidate runs the script BEFORE validation. The purpose is to allow you to do your own "validation" (or other stuff) before the native one kicks in.

If the field is validated as unique and you have entered a non-unique value, this is not known at this point - it will be discovered only when the native validation runs and discovers a duplicate. If you want to check for a duplicate value yourself, you need to use a relationship or a find.

The other thing is that if the script returns false, validation does not occur - but neither is the field modified. Unless your script either corrects the duplicate value or commits the record while skipping validation, you will end up exactly where you started (i.e. inside the field).