ERP Software Logo1

Microsoft Dynamics vendors provide comparisons and opinions to professionals in the ERP/Accounting software selection process

 
 

Tidestone Solutions - Your Business Process Catalyst

Microsoft Dynamics GP and Dexterity


Email | Print

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

The Dexterity programming language was designed in the early 1990s for the implementation of platform independent graphical accounting software. Dexterity itself is written in the C programming language [1]. It was used in the development of Great Plains accounting software.http://en.wikipedia.org/wiki/Microsoft_DynamicsMicrosoft Business Solutions GP, formerly Great Plains Dynamics and eEnterprise, is a Dexterity-written application. Microsoft’s small business line, Microsoft Small Business Manager and Small Business Financials, were also written in Dexterity and use the same http://en.wikipedia.org/wiki/Source_codecode base as Great Plains.

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

2 Responses to “Microsoft Dynamics GP and Dexterity”

  1. >> 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.<<

    I am working on dexterity since 10 years and for each upgrade we never 're-code' with each upgrade.
    Yeah we need to 're-do' some of the codes and modification which were directly made on the GP window, but for code only copy paste will work, I mean you don't need to re-code your script.

  2. Great assesment Darren. And it was a very informative class with Mariano. Still absorbing it all as I work on a highly complex upgrade with 95 users, databases > 200G, from v9 to vGP2013 with dozens of modified forms with vba, and a few alternate forms.