#GPPT Automating or Customizing the Report Destination Window Revisited

David Meego - Click for blog homepageToday we are revisiting the article #GPPT Automating or Customizing the Report Destination Window. In this article we show how Build 29 of GP Power Tools can improve on the methods used previously.

When automating Microsoft Dynamics GP, if a Report Destination modal dialog window opens, it needs to be dismissed so that the rest of the automation code can continue. This article contains a demonstration project that shows how to dismiss the 3 different dialogs used.

Like before GP Power Tools will need to reference the resources in the Dexterity Runtime Engine dictionary, DEX,DIC as two of the Report Destination modal dialog windows are part of the Dexterity Runtime Engine.


To ask GP Power Tools to include the Runtime Engine in its triggering and scripting windows, please add the following Dex.ini setting to the workstations you are using to create the customization:

  • MBS_Debug_ShowRuntime=TRUE

Once this setting has been added, the DEX.DIC will be available in the Trigger Setup and Runtime Execute Setup windows and shows in the Resource Explorer windows.


As mentioned there are three different Report Destination windows, to know what code is needed to dismiss the dialog, you need to know which of the windows is opening. Below is a screenshot of the windows and a description of how each window is called:

Above is the default Dexterity Runtime ‘Report Ask’ form which is automatically displayed when a report is run without a destination being specified. Report Information not bold, no Ask Each Time checkbox.

Above is the Report_Destination form in the Dynamics Dictionary which is normally used by developers to get the destination information before running any processing before run the report with the specified destination. Report Information bold, with Ask Each Time checkbox.

Above is the ‘Report Destination’ form in the Dexterity Runtime that is used with the QueryDest_ Function Library commands and the ReportDestObj form in Dynamics. Report Information not bold, with Ask Each Time checkbox.


The method of ensuring that these triggers do not dismiss all reports is using the ability to Temporarily Disable and Enable triggers available in Build 29. This is better than Starting and Stopping the triggers continuously (which keeps incrementing the trigger tag value), and is simpler than using Memory Parameters as a flag to say when the triggers should be active.

Using the Trigger option to automatic Temporarily Disable the trigger means, it will only be active for a single Report Destination modal dialog. If you want it it active for more than one, you could change this option and then use the MBS_Trigger_DisableSingle Helper function to manually disable the trigger when it is no longer needed.

If you know how many Report Destination windows to expect you could use a numeric Memory Parameter to count up to a value before disabling the trigger and clearing/deleting the Memory Parameter.

The sample code for the project includes three triggers for dismissing the three different dialogs and three scripts to execute so the triggers can be tested. There is also a fourth trigger and script as an example to show how the Memory Parameter counter method can work.

Here is the Project Setup window:

The triggers against the Dexterity Runtime windows still need to use a Window Activate – After Original trigger to work due to the dialog behaving as a system modal dialog. However, the trigger against the Dynamics Dictionary can use the new Window Pre – After Original Delayed trigger which will only run once after a window is opened, but delayed so any initialization scripts have completed execution.

Note: The trigger scripts do not include the default form and default window commands used for a while with Build 28 as we noticed this could cause unexpected behavior when accessing tables not associated with a form AND not generate any error messages. It was decided to remove their use from the default scripts as it was more important for GPPT code to be reliable and easy to debug.

Downloading and Installing

Using Build 29 or later, download the example code, import using the Project Setup window:

The code will be active on next login or after switching companies, or you can use start the triggers manually from the Project Setup window.

More Information

For more information see:



This article was originally posted on http://www.winthropdc.com/blog.

Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.