Quick Tip: Understanding the Dexterity Reject Script command

This 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

Comments

• Anonymous
  April 27, 2011
  Posting by Vaidy Mohan on Dynamics GP - Learn & Discuss www.vaidy-dyngp.com/.../dexterity-reject-script-command-david.html

• Anonymous
  May 03, 2011
  Posting from Mark Polino at DynamicAccounting.net msdynamicsgp.blogspot.com/.../quick-tip-understanding-dexterity.html

• Anonymous
  May 07, 2014
  Hi Dave, Is there a way to abort processing of original code for functions or procedures? Adriaan

• Anonymous
  May 07, 2014
  Hi Adriaan No, there is no way to stop original code for functions or procedures. The usual method is to let the original code run and then back out the actions you don't want and redo the actions you do. You can trigger after original code and change the results from functions and out parameters. You can also adjust inout parameters sometimes to change the behaviour. For example change the data in a table buffer to stop the code working and then restore the value after. You really need source code to see if you can change values to make the code fail. You also might be able to adjust your trigger point to do want you want without stopping original code. For example using the 3 trigger technique. You can capture a table buffer reference in one location in the code and then make changes to the table buffer in a different location. But for a simple abort... not possible, because this will stop the code and all the calls from that code and all the triggers on that code from all the ISV products installed.  Basically, the reason that there is no abort is that it would potentially break core Dynamics and all third party products that were triggering from that code or a child of that code. David

• Anonymous
  May 26, 2014
  Thanks for getting back to me Dave. If I can give you an example of what I would like to do it would make more sense. The Item Stock Enquiry window has severe performance issues on large databases. In my test environment the screen runs for more than 30 minutes to do what my stored procedure does in 12 seconds. If I could override the 'FillScrollingWindow of form ivItemStockInquiry' procedure I could easily populate the scrolling window, now however I need to override all the change scripts of the fields on the main window and do all the calculations in that window, potentially causing problems in future versions of GP. Does that make sense?

• Anonymous
  June 18, 2014
  Ouch, good thing I found this, only wasted a few hours instead of days. I wish things like this were included in the Dex documentation.