filemaker script debugger stuck offscreen

But, as Uncle Ben likes to say, with great power, comes great responsibility. If the result is False, the triggering event is cancelled and our field retains focus.Īs noted above, this gives us a lot of power in our solutions since we can cancel events from occurring. If the script returns a True result, the triggering event is then processed, and the field is exited. The OnObjectExit-triggered script is running but our field still has focus. Since this is a “before-processing”, or pre-event, trigger, the pending event has been acknowledged by the system but the action has not yet taken place. On the flip side, when exiting this field by clicking the mouse outside its borders or by moving to the next object in the tab order, the database engine again recognizes the triggering event and starts the script assigned to the OnObjectExit script trigger. We are unable to cancel the event, because the user has already entered the object before the script runs. The target field has focus as the script is running.

Because this is an “after-processing”, or post-event, trigger, the event has already occurred and been processed. When entering this field by clicking the mouse inside its borders or by tabbing to it in the tab order, the database engine recognizes the triggering event and starts the script assigned to the OnObjectEnter script trigger. Imagine if you will that we have placed a field on a layout with both of these script triggers defined for it. Using logic built into the script, we are able to cancel the triggering event and prevent the users from moving somewhere they shouldn’t go or doing something they shouldn’t do.Ī quick example of this difference would be to look at the OnObjectEnter and OnObjectExit script triggers. In those instances where the script is run before the event is processed, we have an extra level of control in our solutions. The second question we need to answer is “When does the script begin to run relative to the triggering event?” This is important because some script triggers run the script before the event is processed by the database engine while the remaining script triggers execute the script after an event is processed by the database engine. If the script needs to execute when the user exits a specific field, we may write it a different way. We may write the script one way if the event occurs when the user moves to a specific layout. Once we know the physical steps that move us from one task to the next, we are able to translate those actions into the FileMaker space and select the appropriate Script Triggers for our automation. As outlined in Part 1 of this post, we need to understand the physical process our client has asked us to automate. However, there are several broad questions that need answered as we move forward with the intent of automating our workflow.įirst, “Where do Script Triggers operate?” There are three different areas in our FileMaker custom apps where Script Triggers operate – the Window level, the Layout level, and the Object level.

With this wealth of knowledge already available to us, I am not going to go through each Script Trigger and discuss the minutia of each one. Also, if you are part of the FileMaker Community, you have access to Tech Briefs in the Resources area devoted to Script Triggers. There are a number of Knowledge Base articles at about Script Triggers. As you might guess, a lot has already been said about them to this point. We started with 14 at our disposal and that number has grown to 25 as new ones have been added with subsequent releases of the FileMaker Platform. The Script Triggers I am focusing on were first introduced with the release FileMaker 10 in January 2009. While those actions are technically script triggers (lower case “s” and “t”), they are not the events and Script Triggers (upper case “S” and “T”) we are talking about here and now. This then leads us to the question “What is the event?” In FileMaker, we know that a button, a menu item, or even another script can call a script. When talking about script triggers, the best definition I found is that a script trigger specifies that a script runs when an event occurs. In Part 2 of my post, I would like to share some of the key points specific to the FileMaker Script Triggers portion of my “ Workflow Automation with Script Triggers” session. Last week in this space, I shared some thoughts on Workflow as they related to the presentation I was honored to give at the 2017 FileMaker Developer Conference, held last month in Phoenix, AZ.

Filemaker script debugger stuck offscreen