By Steve Endow
This week, I completed a custom Dynamics GP 2013 eConnect integration created as a Visual Studio Tools AddIn. The client wanted a GP menu item to open the integration window, so I used the Menus for Visual Studio Tools library to create a custom menu item.
The integration worked perfectly, and I packaged it for deployment at the client site.
However, during final testing and verification, I encountered unusual window behavior. The custom VST window would sometimes open “CenterScreen” as intended, but other times it would open in the screen’s upper left corner.
After further testing, the window seemed to open centered on the first launch after starting GP. Subsequent openings would position it in the screen’s upper left corner. I attempted various settings, including manually setting the window Location property, to center the window. Despite these efforts, the window would consistently open in the upper left corner, disregarding my code’s manual Location setting.
Random window positions are incredibly frustrating, especially when they appear in the upper left corner for no apparent reason.
Perplexed, I built a new VS Tools project with a test window. When opened from GP, this window functioned correctly, consistently opening in the center. This discrepancy deepened the mystery.
I meticulously compared every window property in my integration project with the test VST project. All properties were identical, yet the behavior differed.
Finally, I noticed a distinction. In my test project, where the window consistently opened CenterScreen, the icon in the window’s upper left corner was different. Instead of the GP window icon, it was a standard Windows Form icon. This suggested it wasn’t a Dynamics GP VST Form but a standard Windows Form. This realization was significant.
I then added a second window, this time a Dynamics GP Form, to the test project. I replicated all the window properties from the Windows Form. Upon launching both windows, the Dynamics GP Form opened in the upper left corner, while the Windows Form opened CenterScreen, confirming my suspicions.
This screenshot illustrates the standard Windows Form opening CenterScreen, while the Dynamics GP Form opens in the upper left corner.
And if that isn’t the most adorable picture ever featured in a Dynamics GP blog post, I don’t know what is.
It appears that altering the Dynamics GP Form’s window Startup Position or Location settings triggers a bug that disrupts proper window positioning, ignoring the set properties. I experimented with various settings, but none reliably replicated the CenterScreen behavior.
After extensive testing, here’s what I discovered:
When StartPosition is set to CenterScreen and the Location value is 0, 0, the VS Tools window will consistently open in the upper left corner. It might position correctly initially, but changing the StartPosition or Location setting seems to make it default to the upper left.
Adding code to set the form Location property during the OnLoad event results in the window opening CenterScreen on the first attempt. However, subsequent openings reposition it to the upper left corner.
Interestingly, changing the Location to a non-zero value, such as 100, 100, allows the Location property to function consistently.
However, there seems to be an additional caveat. Based on numerous tests, setting the Location only works if it’s the first line in the Form Load event. Any code that refreshes the form afterward will cause the Location setting to be disregarded from the second window opening onward.
To summarize:
Set the form Location property to a non-zero value, like 100, 100.
Add this as the very first line in your Form Load event:
this.Location = new Point((Screen.PrimaryScreen.Bounds.Size.Width / 2) - (this.Size.Width / 2), (Screen.PrimaryScreen.Bounds.Size.Height / 2) - (this.Size.Height / 2));
After hours of testing, I believe these techniques provide a workaround for the VS Tools window positioning bug. Further testing suggests that modifying the Location property might be unnecessary if the Location setting is the first line in the Form Load event.
This issue is new to me, leading me to believe it was introduced in GP 2013 or GP 2013 R2. Its subtle nature makes me doubt it will be addressed soon.
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.
You can also find him on Google+ and Twitter

