Alternate forms

An alternate form is a Microsoft Dynamics GP form you customize, then deliver with your integrating application. After the user installs your product, they can use system security to access the alternate form instead of the original. There are several types of customizations you may choose to make:

Add a new window to a Microsoft Dynamics GP form
Add a new menu to a Microsoft Dynamics GP form
Add new fields and tables to a Microsoft Dynamics GP form
Add new form procedures and functions to a Microsoft Dynamics GP form
Add new local fields to a Microsoft Dynamics GP form

It’s important that you do not change existing functionality on the form. This includes removing an existing field from the form, or altering the way in which the accounting system processes information in the form.

Creating alternate forms

If you choose to deliver alternate forms, there are a number of issues you should be aware of. The following sections explain these issues in detail.

Handling updates

Although delivering a customized form can be a very valuable part of your product offering, be aware that you must redo customizations you make to forms and reports when an update is released. It’s important that you acquire beta code as soon as you can to update and test your integration. This ensures that the release of your updated product will synchronize as closely as possible with the general availability release of Microsoft Dynamics GP.

By limiting the number of customizations to forms, your application’s code is more independent of Microsoft Dynamics GP, thereby reducing the impact of maintenance updates on your application. We strongly recommend you limit customizations by using object triggers in your application.

Refer to Updating an Application for additional information about how updates affect your application.

Multiple third-party customizations

The System Manager controls access to alternate forms through system security. Using security, you can grant a user access to either the original Microsoft Dynamics GP form, or to the alternate version of that form. However, if multiple third-party developers deliver the same alternate form, system security allows the user access to only one version of the alternate form.

Scripts

You cannot modify existing field, window or form scripts, but you can attach a script to a focus event (a pre, change or post event) that Microsoft Dynamics GP isn’t using. However, there is a danger that the focus event will be used in future releases. This would inhibit your script from running once you’ve installed your application.

We recommend that you use a focus trigger rather than applying a script directly to a Microsoft Dynamics GP field. Maintenance updates have no effect on triggers.

Using object triggers for navigation

Object triggers allow you reduce the number of customizations made to Microsoft Dynamics GP forms, such as adding navigational buttons, adding additional fields, or attaching form scripts. Triggers also allow multiple third-party developers to provide applications for a single Microsoft Dynamics GP form with fewer conflicts. Refer to Object Triggers, for more information about using triggers in your application.

Keep in mind that triggers may not totally eliminate the need to customize forms. Most likely, you’ll use a combination of triggers and form customizations.

Object triggers are especially useful when tracking additional data in a Microsoft Dynamics GP form. For instance, a third-party developer added two fields to track lead information in the RM_Salesperson form, like the following illustration:

In this case, the third-party developer delivers the entire alternate form as part of the extracted third-party dictionary. With a form trigger, the third-party developer can attach the same functionality to the form without modifying the form directly. The form trigger adds an item to the Additional menu, where the user can access one or more third-party forms related to the Microsoft Dynamics GP form:

By using the form trigger rather than delivering an alternate form, the original form remains available to the user, and updates won’t affect your integration.

Testing alternate forms in test mode

Use Dexterity test mode with your development dictionary to test your changes thoroughly. Prior to entering Dexterity test mode, be sure you copy the Dex.ini file from the Microsoft Dynamics GP installation and replace the one in the folder from which Dexterity is being run. This ensures that Dexterity test mode uses the same startup information as the Microsoft Dynamics GP runtime engine.

Testing alternate forms in a multidictionary environment

Use the following utilities in Dexterity Utilities to build your application dictionary and test alternate forms in a multidictionary environment:

	Step	Description
	1	Extract new third-party resources using the Extract utility.
	2	Transfer alternate forms using the Transfer Dictionary Module utility.
	3	Add product information using the Product Information utility.
	4	Update series resources using the Series Resources utility.
	5	Create an installation file using the Auto-Chunk utility, and install it with an unmodified Dynamics.dic dictionary.

Refer to Packaging Your Application, for information about using Dexterity Utilities to package and install an application in a multidictionary environment.

Once you’ve built your application, be sure to install it with a Dynamics.dic dictionary that’s exactly the same as the one your customers use. Do not install your application with your development dictionary. This can produce unreliable results since you’re not using the same dictionary as your customers will use.