Currently I work a lot with the script triggers in FileMaker 10. They are a great tool to create a user-friendly interface. But working so intensively with triggers also reveals some missing features. For example, a script trigger is active all the time. As soon as a trigger event is assigned to a script, it will always fire, whenever the event occurs. But this effect is not always welcome. The script command New Window opens a new window with the current layout. If it has any layout triggers assigned, it will fire and process the related scripts.

Before FileMaker 10, when we were using plug-ins like zippScript, we had the chance to disable the triggers. Something similar I like to see in a future FileMaker version: a way to deactivate triggers. And chip in an effective trigger management:

• Controlled trigger deactivation (hard- and soft-coded)
• Trigger logs with information about the trigger event
• Additional trigger information, e. g. a list of all defined triggers for the current layout (perhaps in the Layout Setup window)
• Enhanced Script Debugger with more control regarding trigger events, e. g. a ‘Pause on trigger event’ option

Trigger Deactivation

Trigger Deactivation – Something I like to see in a future FM version.

I see two different ways to implement trigger deactivation. In the first way – I call it hard-coded version – a new option is added to script commands, allowing the user to deactivate any trigger event that could be fired when the command is processed. For example, if you use the script command Go to Layout to display a layout with that has a trigger assigned to the event OnLayoutLoad, checking the option Disable trigger will not fire this trigger.

The other way for trigger deactivation is a soft-coded version. Triggers will be disabled until they are enabled again. It requires two new commands:

1. Deactivate Trigger [ Trigger ]
2. Activate Trigger [ Trigger ]

The parameter Trigger could be any specific trigger (e. g. OnLayoutLoad), a trigger group (e. g. Layout), or a value representing all triggers. This will give the developer detailed control when working with triggers. As for the trigger groups, I would suggest the following selection:

As you can see, some triggers belong to different groups, e. g. OnObjectKeystroke belongs the groups Keystroke and Object.

I already suggested some of these ideas at FileMaker feature request. If you like to see this in the next FileMaker version, you could do the same. Perhaps the more people request a feature, the more likely FileMaker will consider it.

Trigger Log

Trigger deactivation is only one part of effective trigger management. Another part is a trigger log, that can provide important information about the trigger events. If problems occur when programming triggers, the trigger log will help the developer to find and correct the problem. Important information are:

• trigger type
• trigger script name and provided script parameter
• environment information like layout, field, and object name
• trigger level (in case of cascaded trigger events)

More Trigger Management

The trigger log provides run-time information about the trigger events. Other information could be available at developing time. It would be helpful to have here a  list with all defined triggers. FileMaker provides already a rudimentary list, but I think, this could be improved. The Layout Setup dialog shows a list with the available and assigned record, layout, and mode triggers. But to see any defined object trigger, you have to select the specific object. You can activate a view option, identifying objects with assigned triggers with a little read asterisk. But first, it does not indicates whether the object has one or multiple triggers assigned, and second, other layout objects may block the red asterisk, making it a guesswork to find the specific object. A list with all assigned triggers for the current layout will save time and developing cost. A second developer, who has not created the layout, would be grateful for such a list.

Another helpful feature could be a trigger-aware script debugger. The debugger knows the option Pause on error. A new option Pause on trigger would be a great feature to debug scripts in a trigger-rich environment. Perhaps in the field Active scripts information about the trigger event could be displayed (Trigger type, trigger level, trigger script parameter, …).

Hands-on

Okay, these are my ideas about trigger management and features I like to have. The last few days I actually work on my own version of a trigger management. It will include trigger deactivation and a trigger log. The other two elements (additional trigger information, enhanced script debugger) will not be part of it. That would require programming inside the FileMaker application.

Check back often, when you are interested in this trigger management. I hope to post the first part of it soon. Leave me a note about your thoughts and your experience with FileMaker triggers. Are there any features you like to see in an effective trigger management? Perhaps I can include them into my version and publish them here.