Microsoft Dynamics AX 2012 Development Cookbook: Customizing Dynamics AX to suit the specific needs of an organization is plain sailing when you use this cookbook of modifications. With more than 80 practical recipes it's the perfect handbook for all Dynamics AX developers.

Forms in Dynamics AX represent the user interface and are mainly used for entering or modifying data. They are also used for running reports, executing user commands, validating data, and so on.

Normally, forms are created using the AOT by creating a form object and adding form controls such as tabs, tab pages, grids, groups, data fields, images, and others. Form behavior is controlled by its properties or the code in its member methods. The behavior and layout of form controls are also controlled by their properties and the code in their member methods. Although it is very rare, forms can also be created dynamically from the code.

In this chapter, we will cover various aspects of using Dynamics AX forms. We start with building Dynamics AX dialog, and explaining how to handle its events. The chapter will also show how to build a dynamic form, how to add a dynamic control to existing forms, and how to make a modal form.

This chapter also discusses the usage of a splitter and...

Dialogs are a way to present users with a simple input form. They are commonly used for small user tasks, such as filling in report values, running batch jobs, presenting only the most important fields to the user when creating a new record, and so on. Dialogs are normally created from X++ code without storing actual layout in the AOT.

The application class Dialog is used to build dialogs. Other application classes, such as DialogField, DialogGroup, DialogTabPage, and others, are used to create dialog controls. A common way of using dialogs is within the RunBase framework classes, where user input is required.

In this example, we will demonstrate how to build a dialog from the code using the RunBase framework class. The dialog will contain customer table fields shown in different groups and tabs for creating a new record. There will be two tab pages, General and Details. The first page will have Customer account and Name input controls. The second page will be divided...

Sometimes in the user interface, it is required to change the status of one field, depending on the status of another field. For example, if the user marks the Show filter checkbox, then another field, Filter, appears or becomes enabled. In AOT forms, this can be done by using the input control modified() event. However, if this feature is required on runtime dialogs, handling events are not that straightforward.

Very often, existing dialogs have to be modified to support eventing. The easiest way of doing that is of course to convert a dialog into an AOT form. However, in cases when the existing dialog is complex enough, probably a more cost effective solution would be to implement dialog event handling instead of converting it into an AOT form. Event handling in dialogs is not as flexible as in AOT forms, but in most cases it does the job.

In this recipe, we will create a dialog very similar to the previous one, but instead of entering the customer number, we will...

A standard approach for creating forms in Dynamics AX is to create and store form objects in the AOT. Using this approach, it is possible to achieve a high level of complexity. However, in a number of cases, it is required to have forms created dynamically. In the standard Dynamics AX application we can see that application objects, such as the Table browser form, various lookups, or dialogs, are built dynamically.

In this recipe, we will create a dynamic form. In order to show how flexible it can be, we will replicate the layout of the existing Customer groups form located in the Accounts receivable module. It can be opened from Accounts receivable | Setup | Customers.

In Dynamics AX, more complex forms consist of one or more sections. Each section may contain grids, groups or any other element. In order to maintain section sizes while resizing the form, the sections are normally separated by so-called splitters. Splitters are not special Dynamics AX controls; they are group controls with the properties modified so they look like splitters. Most of the multisection forms in Dynamics AX already contain splitters.

In this recipe, to demonstrate the usage of splitters, we will modify one of the existing forms that does not have a splitter. We will modify the Account reconciliation form in the Cash and bank management module, which can be opened from Cash and bank management | Bank accounts list page, by clicking on the Reconcile | Account reconciliation button in the action pane, and then selecting any of the existing records and hitting the Transactions button. In the following screenshot, you can see that it is not possible to control...

Quite often people who are not familiar with computers and software tend to get lost among open application windows. The same could be applied to Dynamics AX. Often a user opens one form, clicks a button to open another one, and then goes back to the first one without closing the second one. Sometimes this happens intentionally, sometimes not, but the result is that the second form is hidden behind the first one and the user starts wondering why it is not possible to close or edit the first form.

Such issues can be easily solved by making the child form a modal window. In other words, the second form always stays on top of the first one until closed. In this recipe, we will do exactly that. As an example, we will make the Create sales order form a modal window.

In the standard Dynamics AX application, there is a class called SysSetupFormRun. Every runtime form inherits that class; therefore the class could be used to override some of the common behavior for all Dynamics AX forms.

For example, form background color could be changed depending on some parameters, some controls could be hidden or added depending on specific circumstances, and so on.

In this recipe, we will modify the SysSetupFormRun class to automatically add an About Microsoft Dynamics AX button to every form in Dynamics AX.

Dynamics AX has a very useful feature that allows saving of the latest user choices per user per form, report or any other object. This feature is implemented across a number of standard forms, reports, periodic jobs, and other objects, which requires a user input. When developing a new functionality for Dynamics AX, it is recommended to keep it that way.

In this recipe, we will demonstrate how to save the latest user selections. In order to make it as simple as possible, we will use existing filters on the General journal form, which can be opened from General ledger | Journals | General journal. This form contains two filters—Show and Show user-created only. The Show filter allows journals to be displayed by their posting status and the Show user-created only toggles between all journals and the currently logged in user's journals.

Frequent users should notice that some of the Dynamics AX forms use tree controls instead of commonly used grids. In some cases, it is extremely useful, especially when there are parent-child relationships among records. It is a much clearer way to show the whole hierarchy compared to a flat list. For example, projects and their subprojects are displayed in the Projects form of the Project management and accounting module and give a much better overview when displayed in a tree layout.

This recipe will discuss the principles of how to build tree-based forms. As an example, we will use the Budget model form, which can be found in Budgeting | Setup | Budget models. This form contains a list of budget models and their submodels, and although the data is organized using a parent-child structure it is still displayed as a grid. In this recipe, to demonstrate the usage of tree controls, we will replace the grid with a new tree control.

Anyone who has performed a Dynamics AX application installation or upgrade has to be familiar with standard checklists. Normally, a checklist is a list of menu items displayed in a logical sequence. Each item represents either mandatory or optional action to be executed by the user in order to complete the whole procedure. In custom Dynamics AX implementations, checklists can be used as a convenient way to configure non-standard settings. Checklists can also be implemented as a part of third-party modules for their initial setup.

In this recipe, we will create a checklist for user-friendly ledger budget setup. The checklist will consist of two mandatory items and one optional item.

Dynamics AX has a very useful feature, which allows the user to open the main record form with just a few mouse clicks on the current form. The feature is called View details and is available in the right-click context menu on some controls. It is based on table relationships and is available for those controls whose data fields have foreign key relationships with other tables.

Because of the data structure integrity, the View details feature works most of the time. However, when it comes to complex table relations, it does not work correctly or does not work at all. Another example of when this feature does not work automatically is when display or edit methods are used on a form. In those and many other cases, the View details feature has to be implemented manually.

In this recipe, to demonstrate how it works, we will modify the General journal form in the General ledger module and will add the View details feature to the Description control, allowing users...