This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
I have seen this issue come up a number of times. Trying to automate processes which involve reports and wanting to automate the Report Destination window. Sometimes you can add the Report Destination to Visual Basic for Applications (VBA) and sometimes the system will not add the window to VBA. This post will explain the reason for this “weird” behavior.
One thing about “weird” behavior when it comes to computers, is that once the explanation has been discovered, it all makes perfect sense and the computer is just being logical.
The primary fact for this issue is that there are actually two different Report Destination windows:
- In the Dex.dic. This Report Destination window is part of the runtime engine and is opened when a report is executed without the destination being specified in the Dexterity Run Report code.
- In the Dynamics.dic. This Report Destination window is used by developers to ask for report destination information in advance. This information is then passed to the report writer when the developer calls a report, usually after some sort of temporary file processing.
The first Report Destination window from the runtime cannot be customized by VBA or Dexterity. You cannot add it to VBA and you cannot register a Dexterity trigger against it. [Edit] In the more recent builds of Dexterity it is possible to register a cross dictionary trigger against the Dex.dic using Dictionary ID = 1.
The only interactions that are possible with this window are by using the VBA’s SendKeys command to control using keyboard key strokes or using pass through Dexterity sanScript.
The Dex.dic can be referenced as dictionary 1 with the execute() function or the unsupported method of calling Dexterity from VBA via the Continuum Integration Library. Please see the materials in the following post for more information on these methods:
The second Report Destination window which is part of the core Dynamics.dic application dictionary and can be referenced easily by both VBA and Dexterity.
I hope this explains the apparent inconsistent behavior.
David
10-Jan-2011: Mention that cross dictionary triggers against Dex.dic are possible now.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.
Winthrop Development Consultants Blog 
Posting from DynamicAccounting.net
http://msdynamicsgp.blogspot.com/2009/11/automating-or-customizing-report.html
LikeLike
David,
Sorry but again, i disagree with you on below. We can register trigger for report destination window.
>>The first Report Destination window …you cannot register a Dexterity trigger against it. >>
Thanks,
elmo
LikeLike
Hi Elmo
Registering triggers against Dex.dic was originally not possible as the product ID 1 did not appear in the Dynamics.set. In more recent builds of Dexterity (not sure when) this became possible.
I have updated the article to mention this.
Thanks for your feedback.
David
LikeLike
>>>Thanks for your feedback
Do you really mean it? LOL
>>> In more recent builds of Dexterity (not sure when) this became possible.
Nops It's not with recent builds but it was as old as GP8, I applied it myself.
Anyway it was just to tease someone who think 'David is always right', your big fan and someone I know.
Of course you know him too.
LikeLike
Hi Elmo
Absolutely, I love feedback … even if it is to correct something. There is always something new to learn.
I originally tried triggers on the dex.dic back in v5.1 when I was testing the new cross dictionary trigger commands Dave Gaboury was working on. They did not work back then, and I never tried again until the issue was raised again recently.
I am not sure what version it started working on, but I am glad it works now.
Quote of the day: "There was one time I thought I was wrong…. but I was mistaken.". 🙂
David
LikeLike
"There was one time I thought I was wrong…. but I was mistaken.".
Nice one, applies to all of us 'Humans'. 🙂
elmo
LikeLike
Great article!
LikeLike
Using VSTools, is there anyway to control the 'Report Destination' window that pops up when transferring a Sales Order to Invoice. Alternatively, can report options be changed so that no reports are printed.
Andrew
LikeLike
Hi Andrew
I had responded to this once already, but the comment was somehow deleted. I will try again.
The 'SOP Transfer Log' report is executed from two locations and is run without any destination information provided. This means that the Report Destination window used in the one in the DEX.DIC, which cannot be controlled via VBA or VSTools.
It might be possible to control it with cross dictionary triggers and execute() commands from Dexterity accessing Dictionary ID 1.
I think you would have better luck stopping the report from printing in the first place. This could be achieved using a similar approach to the Three Trigger Technique in Dexterity:
blogs.msdn.com/…/using-the-dexterity-three-trigger-technique-part-1.aspx
You would need to trigger before and after the SOP_Xfer_Document_WIN_POST script to set and clear your flag. Then when the Check_For_Children of form SOP_Xfer_Document script is run you would need to store the previous values and then temporarily change the values of 'SQL Server' of globals to 5 (which is DYNAMICSLITE) and the value of the '(L) Batch Error' field to 0 (which is OKAY). Under these circumstances the report will not print. The after SOP_Xfer_Document_WIN_POST trigger can restore the values.
Below is an excerpt of the code from SOP_Xfer_Document_WIN_POST
<GP Source code removed by PTR>
The other location is before and after the SOP_Xfer_Document l_Done_CHG script. Again use the Check_For_Children of form SOP_Xfer_Document script. The only difference is the field this time is '(L) Document Error' rather than '(L) Batch Error'.
Hope this helps
David
LikeLike
Hi David,
I found your articles to be very helpful.
I recently ran into having to automate the Report Destination window as well. I made the assumption that the Report Destination window is a standard Windows modal dialog. I was able to obtain control over this window and following your example I wrote my first article hoping it would help other fellow programmers in dealing with this issue:
http://www.codeproject.com/…/Closing-Microsoft-Dynamics-GP-Report-Destination-w
Thank you,
Paul
LikeLike
Hi Paul
Thanks for the information and the link to your article.
David
LikeLike
David & Paul,
I have a VSTools GPAddIn that processes many tasks and some have the Report Destination screen open when I don't want it to. After reading this post and looking at Paul's Closer solution, I thought I had solved the problem. I wanted to stay with VSTools because I'm not a Dexterity programmer. Paul's Closer code works great as long as the machine running GP and the AddIn always has the console logged in. In my case, the automation is running on a server in our computer room and is accessed via RDP. Once you disconnect the RDP session, the keyboard is no longer available and the SendKeys command fails even though GP and the AddIn are still running. The Report Destination screen stays open and your automation freezes until that window is closed.
I knew about the Continuum API and executing sanScript code from a .Net application so I looked at doing that. By executing sanScript code to close the window, I wouldn't have the issue of SendKeys failing when the console window was closed.
Here's the modification I made to Paul's Closer.cs code and it works great.
1. Add a reference to the Dynamics Continuum Integration Library in my .Net application.
2. Comment out the two SendKeys.SendWait commands in the closerTimer_Elapsed procedure.
3. Added the following code to the closerTimer_Elapsed procedure.
Int32 ErrorCode = 0;
String ErrorMessage = String.Empty;
Dynamics.Application GP = (Dynamics.Application)Activator.CreateInstance(Type.GetTypeFromProgID("Dynamics.Application"));
GP.CurrentProductID = 0; // Dynamics.dic
ErrorCode = GP.ExecuteSanscript("run script '(L) Cancel' of window 'Report Type' of form 'Report Ask';", out ErrorMessage);
GP.CurrentProductID = 1; // Dex.dic
ErrorCode = GP.ExecuteSanscript("run script '(L) Cancel' of window 'Report Type' of form 'Report Ask';", out ErrorMessage);
Notice that the ExecuteSanscript is called twice. Once for the Report Destination window when called in the Dynamics.dic and once for the Dex.dic. I do this because depending on what calls the Report Destination screen means you would have to execute the closing sanScript in that dictionary and you don't know which one is being used.
You can check the value of ErrorCode to see if it's zero or not. If it's zero, there wasn't an error. If it's not zero, the ErrorMessage will tell you what the problem is.
I hope others find this as useful as I did.
LikeLike
the GP Web Client, if you have Word Templates Enabled, it defaults ALL reports to TEMPLATE in the report destination window. I want to do a simple customization that will check to see the Template Configuration Setup tables each time the Report Destination window is loaded in GP and set the Report Type to Standard or Template based on whether the Word Template is set as the Default. It would look something like below. Its just the basic logic(obviously the syntax is not good but you get the picture) but the query is good. My question is: Could I accomplish this using VS Tools for the Web Client?
Declare TempID
TempID = TemplateIDFrom ReportDestinationWindow
Select * from DYNAMICS.dbo.SY20000 a
inner join DYNAMICS.dbo.SY20020 b on a.TemplateID = b.TemplateID
where CMPANYID = 3 and a.TemplateID = TempID and IsDefault = 1
IF EndOfFile then
Set ReprtType = Standard
Else
Set ReportType = Template
End If
Thanks!
LikeLike
Hi David
You could use Visual Studio, Dexterity or even GP Power Tools triggers to adjust the behaviour of the window.
David
LikeLike