Forms Best Practice Checks

This topic describes the best practices for standard view and data-entry forms. Best practices for lookup forms are described separately. Best practices for form properties are described in the topics that are listed in the See Also section.

Form Name

---

The name of a form should be identical to the name of the table that is used as its data source.

Tabbed Pages

---

All forms should automatically open on a tabbed page.

All data entry and view forms that use tables with the table groups—group, main, or transaction—must have two tabbed pages :

• Overview with a grid, (@SYS9039)
• General with non-grid table data groups, (@SYS2952)

These tabbed pages enable the user to choose between the spreadsheet style of the grid, and the form style of the non-grid view. If you do not use the previous labels for the first two tabs of a data entry form, a best practices warning appears. 

A form should open on the first tabbed page. The Tab property for the Tab control in your form design must be set to Auto. 

Do not set the HelpText property for a TabPage form or a group on a tabbed page unless the form is a wizard, or unless the group has the FrameOptionButton property set. 

Buttons

---

Place buttons in a ButtonGroup control with the following property settings:

• Left - Set to Right edge
• ArrangeMethod - Set to Vertical

Buttons and their associated menu items must fully support multi-selection in the grid or grids.

Command buttons should not be defined.

Keep Default Settings

---

When you design forms, their properties should retain their Auto or Default settings. This is the primary form-design rule.

Many aspects of form design are defined in the data source table. They shouldn't (usually) be overridden in the form. These form-design aspects include the following:

• Relations
• Delete actions
• TitleField1 and TitleField2 properties that are used by the caption method
• Labels used as captions on field groups, on controls, or on the table field group controls
• Order of the fields in field groups is reflected when the field groups are displayed on the forms
• AutoReport field group that specifies the initial print layout

The first index is used for sorting in the form, unless this behavior is overridden.

Enable IntelliMorph Features

---

You should enable all IntelliMorph features in forms. Following are examples of how to enable these features:

• Construct the form by using a menu item and a MenuFunction object. This is automatically done when you use menu items.
• Prioritize your data design elements (controls) as follows:
  • Table field groups with the AutoDataGroup property set to Yes
    –or–
    Table field groups (with the AutoDataGroup property set to No)
    –or–
    Table fields
    –or–
    Display and/or edit methods—preferably from the data source table
    –or–
    Controls that are based on extended data types
• Ensure that labels, and to a certain extent HelpTexts, are not overridden on the controls—especially not with the same value as the one supplied from the Field, the display and/or edit methods or the extended data type. 

Ensure that the Caption is not overridden on the Table field groups bound group controls, and especially not with the same value that is supplied from the Table field group.

Form Size

---

Forms must have the ability to be resized—the Width and Height properties on the Tab control and the Grid control must be set to column width/column height.

A form must fit a screen that has a 1024 x 768 resolution. Because the status bar, caption, and toolbars take up about 100 pixels vertically, and the menu bar in the Navigation Pane takes up 200 pixels, the maximum size of a form should be 824 x 668. If you exceed this size, a best practices warning appears.  If you exceed 1080 x 924, a best practices error appears. 

Form Initialization

---

If a form cannot be started (initialized) correctly, you must inform the user and end the process. For example, if the form has to be started by using certain parameters and is not, throw an error as soon as possible. Provide a straightforward, descriptive error message that states the problem. The following example shows an error being thrown.

void init() 
{
    if (!element.args() 
        || element.args().dataset() 
        != tablenum(BOMCalcTable))
        throw error(Error::MissingParameter(element));
    super();
    ...
}

Printing from Forms

---

By default, printing is available from all forms with a data source through the Auto Report facility.

If a special report has been created to support general printing from the form, implement it on the form's user interface. Override the standard print method on the form. The range (amount) to print must by default correspond to what is on the screen. The report prints when the Print icon is activated—an explicit Print button should not be added to the form.

If (in rare cases) a Print button is needed, implement it by using a Print CommandButton control.

Implement the call to the report by using its menu item (depending on the functionality needed) as shown in the following example.

void print()
{
    new MenuFunction(menuItemOutputStr(...),
                     MenuItemType::Output).run([...]); 
}

Reports with more specialized functionality should be added to the form by using menu item buttons.

Dimension Fields

---

If the table has a dimension field (a field based on the Dimension extended data type) that is going to appear on the form, do the following.

1. Create a separate tabbed page named "dimensionTab," positioned as the last tabbed page.
2. Place the Dimension field group as an auto data group on the tabbed page. The FrameType property on the group must be set to None (to avoid duplicated text: A Dimension tab with a Dimension group).

The label for all the dimension names is: @SYS14926, en-us: "Dimension."

ActiveX Control Security

---

ActiveX controls can be a security threat. Note the following security issues:

• ActiveX controls run in the same security context as the Microsoft Dynamics AX client.
• ActiveX controls that are used by Microsoft Dynamics AX should not be marked as safe for scripting.

If an ActiveX control in Microsoft Dynamics AX has a method with a signature and a name that are equal to a public method that is exposed by the ActiveX control, the X++ method is always called when it is referenced from X++ code.

For more information about ActiveX controls and security, see http://msdn.microsoft.com/workshop/components/activex/sec_activex.asp.

Image and Animation Files

---

To help prevent attackers from modifying the contents of image and animation files that are used by your form, ensure that access control lists are applied to the image and animation files.