More triggers, with BEFORE and AFTER; new AfterScriptError trigger

Idea created by arnoldkegebein on Mar 3, 2016

Comment • 5

Active

Score6

I like to have a more detailed trigger system that allows me to choose a trigger that fires before or after the trigger event.

For example:

BeforeObjectEnter
AfterObjectEnter – This is the current trigger OnObjectEnter
BeforeLayoutExit – This is the current trigger OnLayoutExit
AfterLayoutExit
…

A new trigger AfterScriptError – preferable also in a Before version, but I guess FileMaker cannot predict when an error will occur ;-)

This trigger will fire when an error occurs during a script, allowing to log the error and do other proper actions.

Of course the developer could add after each script step a sequence like If[ Get( LastError ) ≠ 0]; Perform Script "XYZ"; End If, but FIleMaker already triggers script errors, wen you select the option "Pause on error" in the script debugger. Why not giving us the option to trigger a script instead of opening the script debugger?

fitch Mar 3, 2016 3:16 PM

BeforeObjectEnter is mysterious. Time is linear. And the distinction between OnLayoutExit vs. AfterLayoutExit eludes me. And we already have a mechanism to deal with errors in scripts, as you noted, so I don't really see what the added value is of AfterScriptError. However, I'm interested in errors that trigger outside of scripts, which is why I suggested Security triggers .

Actions

arnoldkegebein @ fitch on Mar 4, 2016 1:10 AM

BeforeObjectEnter would be very helpful with popovers. Currently, if you use OnObjectEnter the popover is already displayed. Initialize fields and variables in the trigger script requires to refresh the popover, and will at least increasing process time.

Another example is a field styled as checkbox set. If the user clicks into this field, the OnObjectEnter trigger will fire AFTER the value was changed. There is no direct way to know at that time which checkbox value was changed. A BeforeObjectEnter trigger would fire before the value is changed.

For the current mechanism to deal with errors, you have to blow up your code from 15 original code lines to perhaps 30, 40 or more code lines, making it harder to read and understand the actual purpose of the script. Using an OnError trigger will replicate a mechanism that is well known in other programming languages (e. g. JavaScript, try and catch).

The trigger script could at least log the errors with additional information; very helpful when you have to deal with solutions from unknown developers.

Some time ago I worked with MS Access were much more triggers are available. I never used all available triggers, at least not in a single solution, but I was always happy to find the appropriate trigger for the individual situation, giving me much more control to create responsive user interfaces.

Actions

PeterDoern Mar 4, 2016 9:40 AM

Perhaps the answer is to add an option to Script Trigger dialogs: "Execute Before" or "Execute After".

For example, OnObjectEnter:

Execute Before: executes script prior to actually entering the object. A function like Get (ActiveFieldName) would return the active field prior to the script trigger firing.

Execute After: executes the script after actually entering the object. Get (ActiveFieldName) would return the name of the field entered (if it were the target of the OnObjectEnter, naturally).

For backwards compatibility, the option would default to the current default behaviour for the script trigger.

Actions

arnoldkegebein @ PeterDoern on Mar 4, 2016 11:37 AM

First I thought so too, but there might be situations when you want use both triggers, before and after.

Actions

PeterDoern @ arnoldkegebein on Mar 4, 2016 4:04 PM

Good point!

Actions

5 Comments

fitch Mar 3, 2016 3:16 PM
BeforeObjectEnter is mysterious. Time is linear. And the distinction between OnLayoutExit vs. AfterLayoutExit eludes me. And we already have a mechanism to deal with errors in scripts, as you noted, so I don't really see what the added value is of AfterScriptError. However, I'm interested in errors that trigger outside of scripts, which is why I suggested Security triggers .
Like • Show 0 Likes0
Actions
arnoldkegebein @ fitch on Mar 4, 2016 1:10 AM
BeforeObjectEnter would be very helpful with popovers. Currently, if you use OnObjectEnter the popover is already displayed. Initialize fields and variables in the trigger script requires to refresh the popover, and will at least increasing process time.
Another example is a field styled as checkbox set. If the user clicks into this field, the OnObjectEnter trigger will fire AFTER the value was changed. There is no direct way to know at that time which checkbox value was changed. A BeforeObjectEnter trigger would fire before the value is changed.

For the current mechanism to deal with errors, you have to blow up your code from 15 original code lines to perhaps 30, 40 or more code lines, making it harder to read and understand the actual purpose of the script. Using an OnError trigger will replicate a mechanism that is well known in other programming languages (e. g. JavaScript, try and catch).
The trigger script could at least log the errors with additional information; very helpful when you have to deal with solutions from unknown developers.

Some time ago I worked with MS Access were much more triggers are available. I never used all available triggers, at least not in a single solution, but I was always happy to find the appropriate trigger for the individual situation, giving me much more control to create responsive user interfaces.
Like • Show 0 Likes0
Actions
PeterDoern Mar 4, 2016 9:40 AM
Perhaps the answer is to add an option to Script Trigger dialogs: "Execute Before" or "Execute After".

For example, OnObjectEnter:
Execute Before: executes script prior to actually entering the object. A function like Get (ActiveFieldName) would return the active field prior to the script trigger firing.

Execute After: executes the script after actually entering the object. Get (ActiveFieldName) would return the name of the field entered (if it were the target of the OnObjectEnter, naturally).

For backwards compatibility, the option would default to the current default behaviour for the script trigger.
Like • Show 0 Likes0
Actions
arnoldkegebein @ PeterDoern on Mar 4, 2016 11:37 AM
First I thought so too, but there might be situations when you want use both triggers, before and after.
Like • Show 0 Likes0
Actions
PeterDoern @ arnoldkegebein on Mar 4, 2016 4:04 PM
Good point!
Like • Show 0 Likes0
Actions

More triggers, with BEFORE and AFTER; new AfterScriptError trigger

Related Content

Recommended Content

Incoming Links