Developing for Multiple Dexterity Versions and a warning
I recently came across a situation recently that highlighted the importance of using the correct best practice when developing Dexterity applications for multiple versions at the same time.
While working on the Support Debugging Tool build 17, which included the update for Microsoft Dynamics GP 2013, I came across an issue where the SDT code for GP 10.0 and GP 2010 became corrupted. The result of the corruption was that the local buttons on the Dexterity forms lost their captions and images, and opening the corrupted windows could cause Dynamics GP to crash.
To understand how the corruption occurred you need to understand the incorrect development practice I was using. To develop the same code across three versions of Dynamics GP, I have three development environments set up (one for each version). I would develop the code changes in the latest Dynamics GP version and then export the updated and new resources from the dictionary and import the files into the older versions. To handle features only available in later versions, I would use the #if and #end if precompiler directives which allow conditional compilation of code based on the version number stored in a constant.
This method has worked for developing the Support Debugging Tool development since version 8.0. However, even though the method has worked in the past, it is not best practice and no longer works.
After some research, I found that there has been a subtle change to the format of the exported file for form resources. The way that images attached to Pushbutton and Visual Switch local fields are defined in the file has changed. The Image Type for the fields used to be defined as "Mixed" with the type being based on whether the Static Items of PictItem (for Pictures) or ImageItem (for Native Pictures). In Dexterity 12.0, it uses "Picture" and "Native Picture" respectively.
Without going into more detail, the bottom line is that changes to the file formats can be made in later versions of Dexterity to fix bugs or support new features and that the later versions of Dexterity can always read the older formats, but the older versions of Dexterity might not be able to read the newer formats. This approach will always allow Dexterity applications to be upgraded using Source Code Control.
So, the lesson I learned, when developing the same code for multiple versions at the same time, Best Practice is to develop in the oldest version and export the files and roll the code forward by importing into the later versions. This does make it harder to develop code that leverages features only available in the later versions, but does avoid the corruption issues which can occur when trying to roll code back versions rather than rolling forward.
To fix my SDT code, I exported all the forms from the GP 2013 dictionary and then used a series of find and replaces (see below) using Notepad.exe, then imported the adjusted file into the older development environments.
- Find "Picture" Replace "Mixed"
- Find "Native Picture" Replace "Mixed"
- Find ListView change back to Picture
- Find TreeView change back to Picture
- Find VisualSwitch change back to Picture if Static Items are PictItem
- Find VisualSwitch change back to Native Picture if Static Items are ImageItem
Hopefully, you can learn from my mistake here.
David