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:
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 posts for more information on these methods:
Cross Dictionary Dexterity Development Microsoft Dynamics GP Technical Airlift 2008
Cross Dictionary Dexterity Development
Microsoft Dynamics GP Technical Airlift 2008
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.
Posting from DynamicAccounting.net
http://msdynamicsgp.blogspot.com/2009/11/automating-or-customizing-report.html
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
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.
>>>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.
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.". :-)
"There was one time I thought I was wrong.... but I was mistaken.".
Nice one, applies to all of us 'Humans'. :)
Great article!
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
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
PLEASE READ BEFORE POSTING
Please only post comments relating to the topic of this page.
If you wish to ask a technical question, please use the links in the links section (scroll down, on right hand side) to ask on the Newsgroups or Forums. If you ask on the Newsgroups or Forums, others in the community can respond and the answers are available for everyone in the future.