A few days ago I wrote about an odd behavior in VS Tools where an event handler wouldn't fire if a VS Tools window initiated an event on a GP window.
Specifically, on the GP 2013 Void Historical Payables Transactions window, when you click on the Mark All button, two different dialog boxes appear. (the dialogs are not present on GP 2010)
I needed to suppress those two dialogs. I wrote an AddIn with an event handler for the BeforeModalDialog event, which worked perfectly when I clicked the Mark All button in GP.
pmVoidPaymentsWindow.BeforeModalDialog += new EventHandler
But if I had a VS Tools window "click" that button, the event handler did not fire. At all.
I was stumped. After hours of testing and trying various scenarios, I figured it was a bug, and I would have to develop a workaround. I tried 2 or 3 different workarounds--all of which worked fine in GP, but none of which worked when a VS Tools window clicked Mark All.
For instance, I added VBA script to the window to see if VBA could take care of the dialogs.
Private Sub Window_BeforeModalDialog(ByVal DlgType As DialogType, PromptString As String, Control1String As String, Control2String As String, Control3String As String, Answer As DialogCtrl)
If Left(PromptString, 61) = "Your selection may include payments that have been reconciled" Then
Answer = dcButton2
ElseIf Left(PromptString, 69) = "Your selection may include credit card payments with related invoices" Then
Answer = dcButton2
Once again, this worked fine if I manually clicked the button in GP, but when my VS Tools window clicked the button, the event handler would not work and the dialogs would appear.
I briefly considered trying Continuum, but I couldn't easily figure out what script to use to click through the dialogs. I momentarily thought of using a macro, but didn't want to go there.
While desperately searching for a solution, I begged for help from Andrew Dean and Tim Wappat, both of whom are expert .NET and GP developers. They both confirmed the issue and were puzzled. They came up with a few workarounds to try, but nothing seemed to work.
I then finally resorted to using the Windows API to detect the dialog boxes and click through them, completely outside of the GP dev tools and VS Tools. After a day of research and testing, I finally got that to work. It was a kludge, but it did work, literally clicking the Continue button of the dialog boxes as they flashed up on screen.
And then today, Andrew created a VS Tools test app that was able to get the BeforeModalDialog event to fire properly. Before I had a chance to review it, Tim Wappat had reviewed the code and found the reason: Andrew had used a standard Windows Form rather than the VS Tools DexUIForm for his test window.
Sure enough, when I modified my test window to inherit from the Form class rather than the DexUIForm class, the BeforeModalDialog event handler worked properly when my window clicked the Mark All button.
public partial class FrmVoidTest : Form //DexUIForm
So there it was--an apparent bug in the DexUIForm class caused the event handler for the Void Historical Payables window to not fire. And strangely, it only seems to occur with some windows--for instance, the problem does not occur with the SOP Transaction Entry window. So there is something about the Void Historical Payables Transactions window that triggers the bug.
Unbelievable. It took me 3 full days to try several different workarounds and it turns out that changing one word on line line of code was the solution. It's problems like this that make me frustrated with Dynamics GP. Incredible waste of time for such a seemingly small problem, yet that problem is critical, and prevents me from completing my project.
The only good thing is that I learned quite a bit about the plumbing of VS Tools and Dynamics GP windows, and I am now also familiar with the Win API code to detect, analyze and automate actions on Windows applications. But it was a painful journey.