FileMaker's script triggers can be problematic if you don't properly test and debug the user interaction flow. Some developers, perhaps even yourself, avoid script triggers for this reason.

However, script triggers can be incredibly useful. Unlike JavaScript in the Web Viewer or other environments (anyone remember HyperCard or Adobe Flash?), which have numerous possible events, FileMaker offers a limited set of events called Script Triggers.

One of the best aspects of Script Triggers is that they are linked to specific objects, areas, or actions. This differs from writing scripts that must handle various conditions and situations. With Script Triggers, you can make a particular area of FileMaker function autonomously, handling its own tasks. The first step to feeling comfortable with Script Triggers is learning how to manage them when you don't want them to execute.

In this video, I revisit a database created in 2010, which remains valuable for learning what Script Triggers can do. Let's walk through a concrete example of how you can rethink your use of Script Triggers.

Click the title or link to this article to view the video.

View the full article