Try this approach:
Set Variable [$$TriggersOff ; value: True]
Put the rest of your script here
Set Variable [$$TriggersOff ; value: False ]
This is a method you can use to keep a trigger controlled script from calling itself and if you set up other script trigger controlled scripts with the Same IF block, you can use the same method to keep your scripts from tripping them as well.
I tried your suggestion, but I think I'm definitely missing something. What turns $$TriggersOFF to true so that it processes the script steps? As it stands, it checks if $$TriggersOFF is true, then makes it true, but the end of the block makes the global false, so where do we make it true, so that it executes once?
Thanks for the reply
If step should read
If [NOT $$TriggersOff]
I had figured something like that and had tried that before, but it behaves the same as if it wasn't there (endless). You have to add an else before you change global back to false. This works OK, but not as I want, because the second time around, while the global is still true, the focus moves off to the next field. Where as I want it to stay in the same field that triggered the script. As it turns out I had tried something similar, but just by using the fields' value. If it was empty, don't do any of the script steps, which prevents the go to field step, but on second pass (when field is empty), it moves to next field. It seems odd behaviour.
I just did some tests.
My tests indicate that the script does not trip its own trigger.
The script leaves the cursor inside the field and thus almost any action you take--except to enter data into the field--will trip the trigger as that action will exit the field.
This creates the illusion that the script is tripping it's own trigger but it is merely creating circumstances such that almost any user action will trip it once they need to do something other than enter data into this field.
I think you need to rethink your interface design so that there is no need to put the cursor back in the field at the end of this script.
The OnLayoutKeystroke trigger could, for example, put the cursor into this field if it is not already located there.
You can also use OnObjectKeystroke to check for the key that was pressed and if it's tab, enter or Return, exit the field and process the data entered. This allows you to click with the mouse on buttons and menu options without tripping any trigger on this field.
I've used the debug tool, and it definitely triggers itself for me right after the goto field step. I don't have to do anything in the field; it keeps calling itself. Did you use a different step to put the cursor back in? I thought maybe Freeze Window might cause a problem, since I didn't refresh before it ended, but it doesn't seem to make any difference.
Thanks for the options, though!
In that case I suggest posting your script.
To post a script to the forum:
- You can upload a screen shot of your script by using the Upload an Image controls located just below Post A Answer.
- You can print a script to a PDF, open the PDF and then select and copy the script as text from the opened PDF to your clipboard for pasting here.
- If You have FileMaker advanced, you can generate a database design report and copy the script as text from there.
- If you paste a text form of the script, you can use the Script Pretty box in the Known Bugs List database to paste a version that is single spaced and indented for a more professional and easier to read format. (Use the HTML option on the database tab panel and paste the text into the forum's HTML editor.)
I used this simple script with my OnObjectExit trigger:
Set Field [Table::triggerField ; ""] //clear the data
Go to Field [Table::triggerField ]
When I run the script--tested this with and without the debugger enabled, I see the data I entered disappear, the cursor remains in the field, but anything I try next trips this trigger again and I have to modify the script before I can do anything else except force quit.
The layout is used for testing had two fields on it and nothing else. Both fields were in the tab order.
I am testing in Windows XP, but will be very suprised if this turns out to be a mac specific issue.
That's what I use as my last two steps. But I found the mechanism that makes it re-trigger itself. During the processing of what was typed in the field, I have to go to other layouts in order to add or delete records from other tables. These jaunts to other layouts is what makes it loop endlessly.
Strangley enough, I reduced my script to just those two lines you posted by disabling the other steps, and it wouldn't stay in the trigger field. It would always go to next field. Even with debug, the cursor would be there, then when it exits, it goes to next field. I put same script on the button and removed the field trigger, and it works perfectly, as you'd expect.
Thanks for all of your help and testing, Phil!
That's amazing! Thanks for that. It works even with the goto layouts! One simple step I wouldn't have thought of in a million years!
You can read more about exit Script [false]--which is NOT the same as Exit Script--the one exception to the "Null = False" rule in fileMaker if you look upSetting up script triggers in FileMaker help. There's a chart there that identifies which triggers can be affected by this use of Exit Script.