I love writing these sorts of articles. My good friend and fellow MVP, Mariano Gomez, has been using GP Power Tools to assist him in his role as Development Manager at Mekorma and has written blog articles about his experiences.
GP Power Tools removes much of the complexity and time needed for Cross Dictionary development in Dexterity.
Normally, Dexterity development involves adding your custom code into a core Dynamics.dic dictionary. This means you can modify core Forms and Reports to create alternate versions and you can use any resources (datatypes, fields, tables, constants, messages, etc.) and can call any of the existing scripts (even if you cannot “see” them once source code is removed).
You can test your code within Dexterity and once your code is finished, all your additions are extracted out and modified forms and reports are copied into your extracted dictionary. Then this extracted dictionary is used to create your self distributing dictionary chunk file.
In Dexterity terms, the core Dynamics.dic dictionary is first party and any other dictionary is third party. So Third party dictionaries can be created by Microsoft, partners as customisations or ISVs (Independent Software Vendors) as products.
Cross Dictionary development refers to integrating your third party product with any other third party product. Each third party product can easily see and use resources in the core Dynamics.dic, but writing code that works between two (or more) third party products is much more complex.
The issue is that while in the Dexterity development environment, we only work with a single dictionary. Our development dictionary is based on the core Dynamics.dic and only has core resources and resources we have added. None of the resources for other third party dictionaries are available. This has the following consequences:
- All references to resources must use runtime compiled code via the execute() function. This is also known as pass through sanScript or pass through Dexterity code.
- All calls to procedures must use the call with name in dictionary command.
- All trigger registrations must use the Trigger_RegisterByName() variants of the commands.
- All code should be conditional after checking the third party product is installed using the Launch_GetProdPosition() command.
- Testing must be in runtime mode as the third party dictionary is not available in test mode.
Before GP Power Tools, you would need to create a combined dictionary by combining the third party product with a Dynamics.dic dictionary so you could see the resources in the 3rd party dictionary such as tables, forms and windows without [Not Found] errors.
Then you could write yourpass through code (hoping it would work), compile, chunk and deploy your code and test in runtime mode. If it did not work, you would need to go back to Dexterity, make further changes and repeat the process until you had the final code.
Because of this, I usually doubled the hours of any quotes I supplied when cross dictionary development was involved.
Now with GP Power Tools, you can create and test all your code inside GP (without needing a combined dictionary). Once it is working perfectly, you can generate the pass through code and just cut and paste it into your development dictionary.
Check out Mariano’s articles for the details including screenshots and videos:
- Building Microsoft Dexterity Cross-Dictionary Applications with GP Power Tools – Part 1/2
- Building Microsoft Dexterity Cross-Dictionary Applications with GP Power Tools – Part 2/2
For more information on Cross Dictionary Development have a look at:
- Cross Dictionary Dexterity Development
- Can I customise a 3rd party form with Dexterity?
- Understanding Cross Dictionary Dexterity Development
Hope you found this technique useful.
This article was originally posted on http://www.winthropdc.com/blog.