If you check out Error Messages in the Help file, you'll find more than one error message that relates to failed validation. You can trap for these errors in a script. As well, as I'm sure you know, you can have FMP display a custom message when validation fails. Once you determine which errors to trap with Get(LastError), and there are many ways to script this trapping using the "OR" operator, you're on your way to where you want to be.
Sometimes I set validation rules for the fields, but then use script triggers to trap for the same error. The validation rules make sure that any scripting omissions/errors on my part do not keep the errors from being trapped, but use the scripts to provide a more responsive, and less confusing series of messages trapping specific errors. (You can't set up a custom validation error message that includes a calculation or that presents different messages for different errors, but you can present such messages via scripts that use Show Custom Dialog to inform the user that an error has occurred.
Thanks for the responses. I set up the Error trapping Rick describes, and I'll employ the "double layer" protection PhilModJunk described (validation + error trapping).
I've got the script working now, but I have a question for you: I've heard to avoid using global fields unless necessary, and Im wondering if Im setting myself up for problems down the road.
Here how the global field works with my script: Im using a global field I defined specifically for this script, and placed it on the "deal invoice" layout. A button triggers the script, which brings up a custom dialog box, which has an input field based on the global field. The script performs a find (on the "Properties" TO) based on the input; then the script branches depending on $LastError (401 or 0). As an aside, I realize the "perform find" may result in a found set of more than 1 property. But I figure one problem at a time.
Thanks for the help.
I wouldn't dream of developing in FileMaker without using global fields. Granted, the new global variable based options remove the need for using global fields in a number of situations, but there remains many, many situations where the only practical solution is to use a global field.
Using global fields for scripted finds, is one of the classic uses for which there is no better alternative. If you downloaded my Known Bugs List database, you'd find it uses the exact method you describe, but with a few extra bells and whistles. (I use a new window command so that I can use formatted fields and a portal when collecting criteria from the user.)
Hey that's great, glad to know Im on the right track.
I've downloaded your linked DB, thanks for that. I've found that dissecting other people's databases is a great way to aid FM learning, so thank you again.