Multiple third-party developer issues

Form triggers reduce the number of “typical” customizations made to a Microsoft Dynamics GP form, such as adding a navigational button. By reducing the number of form customizations you make, other third-party developers can deliver enhancements for the same form with fewer conflicts.

Multiple alternate forms

If you don’t use form triggers and more than one third-party developer customizes a Microsoft Dynamics GP form, the accounting system is able to display only one version of the alternate form for a given user; customizations from other third-party developers will have no effect. However, by delivering your enhancements on a third-party form accessed from the Additional menu, multiple third-party developers can deliver enhancements for the same Microsoft Dynamics GP form.

We recommend that you examine the customizations you currently make to Microsoft Dynamics GP forms, and determine whether you can provide the same functionality using triggers.


Menu items

If more than one third-party developer adds functionality to the same Microsoft Dynamics GP form using form triggers, the Additional menu will list several menu items, one for each third-party form.

Duplicate menu item names from multiple third-party developers will appear in the Additional menu with no functional conflicts. To minimize any confusion from possible naming conflicts, we recommend that you don’t hard-code the name of the menu item during the form trigger registration. Instead, refer to a getmsg() string in the registration so users can modify the menu item using the Modifier.

The following example uses the getmsg() function to refer to a message (with the resource ID of 22,233) stored in the dictionary.

local integer l_result;

l_result = Trigger_RegisterForm(form RM_Customer_Maintenance, getmsg(22233), "", script IG_Open_Contact_History);
if l_result <> SY_NOERR then
	warning "Form trigger registration failed.";
end if;


Documentation Feedback