I personally would forget the whole scripting thing.
simply turn on "Unique Value" in the field's options in Manage Database.
Also turn on Validate ALWAYS and opt to display a message if validation fails.
the user will have the options of reverting the field, etc.
Open a new window. Do whatever you like. When you return to the first window, everything will be exactly as you left it.
You won't even have to open a new window.
the field will be validated during data entry or whenver the field's conents are modified.
Thank you for your suggestions. Let me explain why I think both are not practical in my situation.
First, rdowler: I would like to clearify things BEFORE the record is created, and not even start with it in case there already exists one, because the user is specifying a number of data in a lengthy process before creation, and after each of these I check whether a record according to the data the user specified so far can be created, or needs to respecify the last bit of data. I do not want to force the user to restart the whole preliminary process in case the record creation fails in the end.
hbrendel: The instance that needs to determine whether a record exists is a native AppleScript (native meaning included into FM, opposed to external/stand-alone). This is given and cannot be changed. I believe you will therefore see the new window flash, which is inacceptable, as I am building a runtime application for clients. Doing the whole check in a FM script (which would probably prevent the new window from being visible) and call that script from the native AppleScript is not possible, because since the AppleScript is native, the FM script it calls will be postponed to after completion of the AppleScript.
How are they arriving at the found set to begin with. (you could just replicate that)
You could first store the key fields in a temp table and refind the set if you wish.
You need to ask is the found set all that important at all since they were trying to add a new record you may just want to dump them on a blank form layout and leave it at that rather than trying to restore a found set. They could just repeat the arrival at the found set if they needed it again.
But my suggestion is to simply loop through the found set storing the key fields in a temp table as new records
You can store the userID as well in order to bring up the found set again and to remove the temp records once you have found them. That way each user will have their own recent foundset stored.
You can also create a new table occurrence to the same table in your relationship graph. Create a new layout that specifies this table occurrence.
Now you can freeze the window, switch to this layout, perform the find and then switch back to the original layout without modifying it's found set, current record or sort order.
This does not require an applescript to perform, it can be 100% Filemaker script if you wish.
You can also define a "self join" that links one table occurrence of your table to a second by this field. Then the test IsEmpty( Table Occurrence 2::Field ) will be true only if the entered value is unique.
One more thing (because this is still somewhat unsolved for me): How do I freeze the window from within the native AS? Like I said, the native AS thing needs to be taken for granted. So, calling a FM script that does "Freeze Window" is not an option, because the execution gets postponed.
I can't help you with the applescript. Why does this have to be an applescript? (Nothing you've described so far requires an Applescript.)
You may need to consider the second suggestion I made which is to reference a 2nd table occurrence of the same table linked via a self join. I can't give you the syntax, but I imagine that test should be something you can script with AS and it won't require freezing the current window.