WIth OnObjectValidate, if you end your script with Exit Script [False] the cursor will stay in the field and Filemaker's validation dialog will not pop-up. This would enable you to pop up your own dialog and then return the user to the field to make any needed corrections before tripping the script trigger again.
You're a star. The amount of hours I've spent.......
You can use the Exit Script script step within the triggered script to return True or False.
- True: The event that triggered the script proceeds.
- False: The event that triggered the script is canceled.
........I wouldn't mind but I remember looking over that that page to investigate the new triggers in FM11. That's what you get for skimming!
Thinking about the other issue. Maybe a count of records that are archived and a check to see if this is equal to total records. If so, don't perform find, if not equal then perform the find.
Cheers again Phil
Exit Script [False] only terminates some triggering events. You can look this up in FileMaker help.
Some events are executed before the trigger "fires" others after. Only those triggers where it "fires" before the triggering event executes can be canceled in this way as the other events have already executed before your trigger's script is performed.
It's been a very long day. What a schoolboy error:
Another instance where this is causing trouble, but probably easier to solve, is where a constrained set or found set contains no results. Filemaker likes to inform me that no records meet the criteria set in the find. I'm asking this as I have allowed the function of archiving records which means I need to find only records where an archived field is set to null or left blank. If all records have been archived, when refreshing the found set there are no records to be found (as all are archived) and Filemaker dispalys its native message about no records to be found. How can I prevent this?
Set error capture [on] will suppress the "not found" dialog.
I try not to use User Abort [off]--especially in looping scripts--unless it is truly necessary. If I create such a looping script and make a mistake that produces an infinite loop, that strip will keep me from using the escape key (command period on Mac) to halt the run away script. My only option, usually, is to force quit FileMaker which could damage any open FileMaker files. (If a looping script pauses, I've found I can use Filemaker Advanced to open the script debugger and use it to halt the script.)
I can see that when developing, allowing user abort would be benificial under circumstances highlighted above. However, is it wise to allow the end user to abort a scripts that are not based on a search query and one that is crucial to data integrity? Or maybe a script that would normally terminate by changing layout, thus leaving the user in 'limbo?'