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.
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. |
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;