Over the last few weeks I have been asked a number of times about methods of customising a 3rd party form.  This purpose of this post is to clarify what can and cannot be achieved with Dexterity.

Usually, the developer has created a combined dictionary as per the instructions in the Integrating with Third Party Dictionaries materials or KB 930350 .  They then either:

1. Attempt to modify the form in the combined dictionary and then either recreate a chunk or create a modified version of the 3rd party dictionary.
    
2. Transfer the 3rd party into their dictionary, modify it and then attempt to get the modified form used as an "alternate" version of the original.

The problem is that method 1 is in breach of the license agreement and the changes will probably be lost if a service pack or hot fix is applied; and method 2 just does not work as Dexterity does not support alternate versions of 3rd party forms.

Note: There is a section in the "Integrating" conference materials on Modifying 3rd party forms. The method discussed is not recommended as it breaches the Dexterity License agreement (not allowed to ship a modified application dictionary) and also causes problems when applying upgrades and service packs.  The later "Pushing" materials contain a Warning about modifiying 3rd party forms to explain some of the issues.

In summary, there is no supported method of using Dexterity to directly modify a 3rd party form.

Depending on the changes needed to the 3rd party form there are other methods available.

For example:

• If you do not need to change the window, but need to run scripts when various events happen in a 3rd party product; you can use cross dictionary triggers of the form Trigger_RegisterXXXXByName().
   
• If you want to add a new navigation to a 3rd party form to an additional window or task, you can use Trigger_RegisterFormByName() to add to the Extras menu.  You can also add a shortcut key to allow a keyboard shortcut to open the additional window or perform an additional task in your dictionary.
   
• If you want to make a new window open automatically, you can use either form, window or field focus events to open your window with the Trigger_RegisterFocusByName() command.

All these examples can be achieved using cross dictionary triggers from your own dictionary.

If you really need to add a new field, you will need to use one of the following methods:

1. Using Dexterity: Create a parallel synchronised window to allow the adding of the additional fields. A parallel synchronised window is a window in your dictionary which opens and closes with the 3rd party window and uses cross dictionary triggers to stay synchronised on the same record. It displays, deletes and saves its data in a parallel or companion table along with the original data. A parallel table has the same primary key fields as the original, along with the additional new fields.
    
2. Using Modifier and VBA: Add a local field to a modified version of the 3rd party window and store its value in the DUOS (Dynamic User Object Store). You can then use cross dictionary Dexterity triggers to read the data from the SY_User_Object_Store (SY90000) table when needed. See the Modifier - Sales Prospect DUOS Example for more information.
   
   Note: If you are just adding a button for navigation and need it to run Dexterity code, you could use SendKeys to drive the menus to your Extras menu added with a cross dictionary form trigger.  You could also use the unsupported method of running Dexterity sanScript via the Continuum Integration Library.  See the materials from the Microsoft Dynamics GP Technical Airlift 2008 for more information. Using the pass through sanScript method allows you to specify the context of the dictionary to run the code in.

Method 1 allows the customisation to stay completely with Dexterity which is an advantage, but the user interface is spread between two windows. Method 2 is better from the user interface perspective as the new field can be in the same window, but relies on Modifier and VBA for part of the customisation.

Note: You can use Modifier modify the window and then use Visual Studio Tools to create the scripting rather than VBA.  You will need to use the DAG.EXE tool to create the assembly to address the modified version of the window.

In my opinion, if the customer is registered for Modifier and VBA (or the Customisation Site License), using the hybrid method 2 will provide the best solution for the customer.

David

11-Jun-2009: Added note about using Visual Studio Tools rather than VBA for scripting.

24-Nov-2010: Updated post to highlight that direct modification of a 3rd party form is against the Dexterity license agreement and is not recommended.