I am working on a project that involves automating a process in Dynamics GP. Since there is no API for the particular steps I need to automate, I'm having to use the low-tech method of opening a GP window, populating some field values, and clicking a few buttons.
This is fairly easy to do with Visual Studio Tools for Dynamics GP...in concept.
But, unsurprisingly, Dynamics GP seems to always have to have the last word, and such seemingly simple projects are rarely easy.
In my particular case, after I performed the last button click on the GP window, Report Destination windows would appear to print posting reports.
The process I am automating generates not one, or two, or four, but FIVE report destination windows. Yes, it is possible to turn off the reports so that the window doesn't appear, but that change would affect many other processes throughout GP where the client might want to actually print some of the posting reports. It is possible to temporarily update the posting report settings in SQL to disable them, and then quickly re-enable them, but that method runs the risk of disabling at the same time that another user needs the report.
Unfortunately, the Report Destination dialog boxes are not standard modal dialogs that would be detected by the BeforeModalDialog event handler in VS Tools. So, some "off roading" is required.
When I ran into this problem I was lucky enough to find this excellent post by Paul Maxan on the Code Project web site.
http://www.codeproject.com/Articles/801319/Closing-Microsoft-Dynamics-GP-Report-Destination-w
Paul wrote a great article and did a very nice job crafting code that uses the Windows API to detect the Report Destination dialog box and use windows handles and messages to click through the dialogs.
He posted some very nice code that I packaged up into a separate class that can be easily invoked just about anywhere in your VS Tools project.
During my testing on GP 2013, I found that his combination of TAB + ESC didn't work for some reason. After some fiddling, I found that ESC by itself did work, so I have used that in my GP 2013 project.
The Report Destination dialog boxes still flash on screen as they are dispatched by Paul's "Closer" code, but it seems to work well and definitely gets the job done.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
2 comments:
Architecture 101: There are two Report Destination windows: one in the Dynamics.dic dictionary and another that is invoked from the Dex.dic, which sits in the runtime engine. In Paul's article, he couldn't quite explain it, but then again, not too many people can, although he realized this window behaved differently from any other Dexterity window.
The Report Destination invoked by the Dex dictionary, if you look very close, resembles a Win32 window.
Anyways, the Report Destination in the Dynamics.dic dictionary is used to ask for the destination settings (screen, printer, file, and report type, along with whether the user wants to be asked about those settings every time the report is ran) in advance of executing the run report report_name statement. Those parameters are collected from this Report Destination window (remember, in the Dynamics dictionary) and passed to the Dexterity run report statement causing the report to run without prompting for other destination settings. Which other settings you may ask? Well, the run report statement will pop up -- you guess it! -- the Report Destination window in the runtime engine when a destination is not supplied by the developer. This was done to prevent users from thinking that a report was dead in the water if it had to scramble through a lot of data before prompting the user for a destination output.
Throughout GP there's a mixed used of Report Destination windows. Some developers use the straight up run report statement and some developers use the Report Destination window in the Dynamics GP dictionary to ask for parameters prior to running a report. In any case, the settings are read from SY Posting Settings table before they are delivered to either the window in GP or straight to the run report statement.
Maybe I should blog about this stuff.
MG.-
Mariano Gomez, MVP
Thanks for the background Mariano. While there may be an explanation as to the arcane reasons for the different types of dialogs or different dialog behaviors, the practical concern is dealing with them. The background of why the dialogs are appearing is academic.
Since GP has many of these rough edges and design weaknesses, modern developers are forced to come up with these otherwise nutty workarounds, all just to do things like bypass a dialog box that we can't turn off.
Steve
Post a Comment