Quick Tip: Understanding the Dexterity Reject Script command

  • Article

David Meego - Click for blog homepageThis is a Quick Tip post to explain how the Dexterity Reject Script command works.

The Reject Script command is designed to be used in trigger scripts to stop the original code from running. However, it only works in specific situations:

  • The trigger MUST be a Focus trigger on a user interface event. That is registered using Trigger_RegisterFocus() or Trigger_RegisterFocusByName().
     
  • The trigger MUST run before the original code. That is using the TRIGGER_BEFORE_ORIGINAL attach type.

Note: The Reject Script command cannot be used to abort processing of original code for functions or procedures.

When the user interface (focus) event occurs, Dexterity creates a queue of the scripts to be run.  This starts with the TRIGGER_BEFORE_ORIGINAL triggers for each of the products registered against the event, then the original event script, followed by the TRIGGER_AFTER_ORIGINAL triggers for each product registered against the event. For example:

  1. Product A: Before Trigger
  2. Product B: Before Trigger
  3. Original Code for Event
  4. Product A: After Trigger
  5. Product B: After Trigger

So, in this example, only Scripts 1 or 2 can use Reject Script to "drop" the queue and stop any further processing.

Best practice is to only use Before Triggers for validation to confirm that the desired conditions are or are not met, or to capture data needed for the After Trigger code. You must use After Triggers to take actions once it is confirmed that the system will be executing the Original code and After triggers.

If you "perform actions" in the Before script, there are two potential problems that could happen (see script queue above):

  1. Your Script 1 code runs, but Script 2 issues a Reject Script command. So your actions have been executed when the original code was never run.
  2. Your Script 2 code never runs because Script 1 issues a Reject Script command. So your actions are never executed when you expected them to run.

Note: The order which triggers against the same event are run is based on the order that the triggers were registered. If the Startup global procedure is used to register the triggers (which is best practice), then the trigger registrations will be processed in the order the products are listed in the DYNAMICS.SET launch file. So re-ordering products in the DYNAMICS.SET launch file can change the sequence for trigger scripts.

I hope this information is useful to you.

David