Understanding Cross Dictionary Dexterity Development

David Meego - Click for blog homepageThis is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.

A recent newsgroup post has raised the question of whether it is possible to customise an alternate form using Dexterity.  This is covered on my earlier blog post: Can I customise a 3rd party form with Dexterity?

However, I thought I would try and clarify what can be achieved with Dexterity for each of the different situations.

There are two aspects to customizing a form with Dexterity:

  1. Form Layout – We can change the form layout, edit field properties or add new fields.
  2. Trigger Scripts – We can use triggers to change the behaviour of the existing code.

Note: It is possible to use triggers and scripts to change a form’s layout.  You can move or hide fields and you can change various field properties.  This allows some of the functionality of the first aspect while using the techniques of the second aspect.  As the techniques involved are those of aspect 2, this will be grouped into the Trigger Scripts section.

 

Terminology

Below is a table which described the different types of forms we can have in a Microsoft Dynamics GP system:

Form Type Description Location
Original Original form created in the core product Dynamics.dic
Modified Original form changed using Modifier Forms.dic
Alternate Original form changed using Dexterity 3rd Party Dictionary
Modified Alternate Alternate form changed using Modifier 3rd Party Custom Dictionary
3rd Party Original form created in 3rd Party product 3rd Party Dictionary
Modified 3rd Party 3rd Party form changed using Modifier 3rd Party Custom Dictionary

Note: 3rd Party here refers to any dictionary other than Dynamics.dic. The developer can be either Microsoft or an ISV.

 

Changing a form layout

When it comes to modifying an existing form with Dexterity, you can ONLY modify a form that exists in the Dynamics.dic.  This is then transferred to the extracted dictionary to become an alternate form during the chunking process.

If you want to modify a form that exists in any other dictionary, be it an original 3rd party form or an alternate of a Dynamic.dic form, you can only use the Modifier.

Below is the table showing what tools can be used for the different types of forms:

Form Type Method for editing Form 
Original Dexterity to create an Alternate Form
Modified Further use of Modifier
Alternate Use Modifier
Modified Alternate Further use of Modifier
3rd Party Use Modifier
Modified 3rd Party Further user of Modifier

Note: The above table is also relevant for Reports and the Report Writer.

 

Use Triggers to change code behaviour

If the form exists in the Dynamics.dic you can use standard triggers. Standard triggers will work against an alternate, modified or modified alternate version of a form as long as all the fields referenced are still available on the non original version.

If this is an original 3rd party form or you wish to trigger against fields in the alternate window and not in the original window, then you need to use cross dictionary triggers in the context of the 3rd party dictionary.

In your trigger handling scripts need to reference fields that do not exist in the Dynamics.dic they will need to use pass through Dexterity sanScript with the execute() function in the context of the 3rd party dictionary.

If you are working with Modifier added fields then Dexterity cannot “see” them at all and you will need to use Visual Basic for Applications (VBA) for both the event capture and for the handler script.

Note: You could also use the unsupported method of running Dexterity sanScript via the Continuum Integration Library.  Using the pass through sanScript method allows you to specify the context of the dictionary to run the code in.

Below is a table which summarises what type of triggers to use and what type of scripts to use:

Form Type Type of Trigger to be used  Type of Script to be used
Original Standard Trigger Standard Dexterity
Modified If field only on Modified
then Visual Basic for Applications (VBA)
else Standard Trigger
If field only on Modified
then Visual Basic for Applications (VBA)
else Standard Dexterity
Alternate If field only on Alternate
then Cross Dictionary Trigger (ByName)
else Standard Trigger
If field only on Alternate
then Cross Dictionary using execute()
else Standard Dexterity
Modified Alternate If field only on Modified
then Visual Basic for Applications (VBA)
elseif field only on Alternate
then Cross Dictionary Trigger (ByName)
else Standard Trigger
If field only on Modified
then Visual Basic for Applications (VBA)
elseif field only on Alternate
then Cross Dictionary using execute()
else Standard Dexterity
3rd Party Cross Dictionary Trigger (ByName) Cross Dictionary using execute()
Modified 3rd Party If field only on Modified
then Visual Basic for Applications (VBA)
else Cross Dictionary Trigger (ByName)
If field only on Modified
then Visual Basic for Applications (VBA)
else Cross Dictionary using execute()

 

What cannot be changed using Dexterity

A final point about customising with Dexterity: You cannot change any Table Definition (including adding a table relationship) or base resource (including datatypes, fields, formats, strings and messages).  While the change will work in Test mode, it will not be extracted when you create your chunk file as so will fail at Runtime mode.  This is because the resources still have a resource ID below 22,000.  Only new resources (>= 22,000) are transferred when extracting during the chunking process.

The ONLY exceptions are that we can use Transfer Dictionary Module to copy a changed form or report into our extracted dictionary to become an alternate form or report.  If you need to change a base resource, you can use Modifier to edit datatypes, formats, strings and messages.  The Modifier will allow you to change values that “usually” will not break Dynamics GP.

 

For more information on the subject and conference materials showing many useful techniques see the post below:

Hope you find this useful.

David

This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.

10 thoughts on “Understanding Cross Dictionary Dexterity Development

  1. I know this is an old post I am bumping, but I have been looking for a long time for an answer to this and can’t seem to find it. I know this is not a help desk, but any pointers would be greatly appreciated.

    I need to fill a scrolling window from an addin.
    As long as the scrolling window is part of core dynamics, this is no problem.
    However, the scrolling window is in my 3rd party dictionary and I get a runtime error that tells me the object can’t be found.

    I am calling the following function I created and passing it this string:
    “fill window SV_Invoicing_Tax_Distribution_Scroll of form SV_Invoice_Tax_Detail;”

    private void RunSanscript(string sanscript)
    {
    try
    {
    Dynamics.Application compilerApp = (Dynamics.Application)Activator.CreateInstance(Type.GetTypeFromProgID(“Dynamics.Application”));
    string ErrMsg = string.Empty;
    compilerApp.ExecuteSanscript(sanscript, out ErrMsg);
    if (ErrMsg.Trim() != string.Empty)
    {
    throw new Exception(“Error in ExecuteSanscript: ” + ErrMsg);
    }

    return;

    }
    catch (Exception ex)
    {
    MessageBox.Show(“Error in RunSanscript: ” + ex.ToString());
    return;

    }
    }

    Like

Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.