Buttons not persisting size in Dynamics GP add-in
Steve Endow, posted yesterday on Buttons mysteriously resize on VS Tools Dynamics GP Forms -- VST template bug?This could have a big impact as I’m now working against GP2013R2 and so I set about investigating the issue. Thanks to Steve for sending me a ZIP of his example, from that I confirmed the same buggy behaviour on my environment, what is more, I also confirmed it on my own projects in my environment.
A big thanks Steve for pointing this issue out, here are my findings.
Reproduce the issue
Start new Dynamics GP Add-in Project
Add a form into the project
Drag two buttons onto the form
Resize the buttons so one is significantly larger than standard and one is much smaller than standard.
Save the form Form
close the form down, then open it again in the designer view….
Yes the buttons have defaulted to “default” size.
I have tested this with Visual Studio 2012 & 2013 as I remembered running Dynamics GP Tools is not technically supported for VS2013.
This is an interesting behaviour!
Testing
None of the following testing helped:
- Using Visual Studio 2012
- Applications.Dynamics / Microsoft.Dexterity.Bridge / Microsoft.Dexterity.Shell dlls from other copies
- Downloading and installing latest Visual Studio Tools for GP including GP2013R2
- Trying class library projects
To track down what was going wrong I jumped into the designer file, thinking that the design time values were not being persisted in the DynamicsGPForm1.Designer.cs
From the above screen shot, the sizes are as expected, one button longer horizontally than the other. Clearly the designer is ok, so why this behaviour? Forms that inherit from the type DexUIForm (i.e. “Microsoft Dynamics GP Forms” from project >> Add New Item), have some extra goodness in the designer “tray area”, as shown below. One of those is the dexButtonProvider. This component grabs the buttons in the form and adds some extra properties to them, it allow the developer to give the users the same experience from the buttons in an add-in, as they would have from the native GP Dexterity buttons.
-so this component is overriding the drawing of the button, there we have a lead to the answer.
TheDynamicsGPForm1.resx file holds the form resources. If you are “in the know”, then you will know that these providers are persisting design time state through the form resources file, as seen from a snippet below:
<metadata name="dexButtonProvider.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<value>107, 17</value>
</metadata>
<metadata name="dexDefaultColorsProvider.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<value>260, 17</value>
</metadata>
<metadata name="dexLabelProvider.TrayLocation" type="System.Drawing.Point, System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<value>450, 17</value>
</metadata>
We would expect to be seeing a XML fragment for each button in here, but it is missing. The expected missing fragment would like this, for button1;
<metadata name="button1.DexDefaultsSet" type="System.Boolean, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<value>True</value>
</metadata>
If you paste this code in before the final element in the resource file, save and open the form again, amazingly the label size is displayed correctly.
The problem seems to be that at design time, when the button is added to the form, the button provider is not writing the information into the resource file that it needs to bind itself to the button correctly.
Workaround
It turns out there is a work around that forces the form to emit this meta data into the resource file. Simply flip the “Button Type on DexButtonProvider” property of each button on the form. Do this by after creating the button, set the value other than “Standard” and back again to “Standard”.
Now save the form and check the form resource file. The XML that was missing has been generated for the buttons, and it is confirmed by re-opening the form, the buttons will now retain their designed sizes.
Conclusion
There is an issue with both Steve and My environments, or there is a bug in the button provider when used in GP2013R2 and .NET 4.5. I have a work around for now, but may come back to this out of curiosity, perhaps reflecting into the button provider to find the root cause.