Microsoft Dynamics GP and Dexterity

Microsoft Dynamics GP is written in a language called Dexterity.  Wikipedia states the following on Dexterity:

As a developer, I had always steered away from Dexterity as a language to create modifications in GP.  I had heard of and had firsthand knowledge of disaster scenarios where the company I worked for had many Dexterity modifications which needed to be totally re-coded every time we upgraded.  This, of course, extended the amount of time and consulting dollars required to upgrade.  So when I took over the GP administration from the partner, the first thing I did was to replace all Dexterity mods with the much more “upgrade friendly” VBA.  The problem with VBA is that you cannot create UI that matches GP.  So when Visual Studio Tools for Microsoft Dynamics GP was introduced, I jumped on that bandwagon as it supports creating UI that “almost” matches that of GP.

I continued to use a combination of Modifier to modify existing GP windows, VS Tools to create new UI and VS Tools to code it all together until GP 2013 was released.  The challenge with GP 2013 is that VBA & VS Tools UI is not supported by the new Web Client.  The VS Tools code will work, but not the UI components.  Dexterity modifications work without the need to change anything.  This got me thinking.  What is the best method that is in the best interest of our customers in the long term?  I think the answer is a hybrid approach and it all depends on what you are trying to accomplish.  So now I typically use Modifier to modify existing GP windows, Dexterity to create new UI and a combination of Dexterity and VS Tools to code it all together.  So I am sure you are asking, “I thought you said Dexterity was a bad option because it complicates upgrades?”

I recently took a 1 week training course on Dexterity with Mariano Gomez, Microsoft Dynamics MVP & VP at IntellPartners in Atlanta, GA.  His blog is here.   I felt that, as a partner, I at least ought to know the basics for coding in GP’s native language.  I am glad I did as I learned that a lot of what I thought about Dexterity is actually not true.

One main thing that I took out of the training was that the Dexterity code only needs to be re-written at upgrade time if you modify existing GP windows.  Once modified these windows become what is known as “Alternate windows”.  You probably recognize the term from GP security if you have any third party products.  So only alternate resources in GP need to be re-coded at upgrade time.  If you create new resources (windows, forms, fields, tables, etc.) in your own dictionary, then at upgrade time you can simply transfer the resources to the new dictionary version and test.

A second major thing that I learned at the training is that Dexterity, while a very verbose language, was developed to create business applications.  This means that there is very little code that needs to be written to implement basic database functions.  Saving a record to the database, for instance, can be done in 5 lines of code.  To do this with Visual Studio .NET using ADO or VS Tools requires up to 3 times that.  This means that once you get the syntax down, Dexterity coding is very quick.

In conclusion, VBA is dead, Dexterity for new objects, VS Tools and Modifier for existing windows.  Long live Dex!

Thanks for reading,

Darren Woodbrey

Lead Technical Consultant

Tidestone Solutions

- See more at: http://tidestonesolutions.com/dynamics/user-news/microsoft-dynamics-gp-and-dexterity/#sthash.CTUaOrkt.dpuf

Related Posts

1. Success Story with Dexterity Customization in Microsoft Dynamics GP
2. Microsoft Dynamics GP: Customization Is NOT a Bad Word
3. Microsoft Dynamics GP Development Environment Overview