In this chapter, we will cover the following recipes:
Forms in Dynamics 365 for Finance and Operations represent the user interface and are mainly used to enter or modify data. They are also used to run reports, execute user commands, validate data, and so on.
Normally, forms are created using the AOT by producing a form object and adding form controls, such as tabs, tab pages, grids, groups, data fields, and images. The form's 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 code.
In this chapter, we will cover various aspects of using Dynamics 365 for Finance and Operations forms. We start by building Dynamics 365 for Finance and Operations dialogs, which are actually dynamic forms, and then go on to explain how to handle their events. The chapter will also show you how to build dynamic forms, how to add dynamic controls...
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, and presenting only the most important fields to the user when creating a new record. Dialogs are normally created from X++ code without storing the actual layout in the AOT.
The application class called Dialog is used to build dialogs. Other application classes, such as DialogField, DialogGroup, and DialogTabPage, are used to create dialog controls. The easiest way to create dialogs is to use the RunBase framework. This is because the framework provides a set of predefined methods, which make the creation and handling of the dialog well-structured, as opposed to having all the code in a single place.
In this example, we will demonstrate how to build a dialog from code using the RunBase framework class. The dialog will contain customer table fields shown in different groups and tabs for creating...
Sometimes, in the user interface, it is necessary 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 using the modified() input control event. However, if this feature is required on runtime dialogs, handling events is not that straightforward.
Often, existing dialogs have to be modified in order to support events. The easiest way to do this is, of course, to convert a dialog into an AOT form. However, when the existing dialog is complex enough, a more cost-effective solution would probably be to implement dialog event handling instead of converting into an AOT form. Event handling in dialogs is not flexible, as in the case of AOT forms; but in most cases, it does the job.
In this recipe, we will create a dialog similar to the previous dialog, but instead of entering the customer number, we will be...
SysOperation is a framework in Dynamics 365 for Finance and Operations that allows application logic to be written in a way that supports running operations interactively or via the D365 batch server. The SysOperation framework follows the MVC (Model-View-Controller) pattern. As the name implies, the MVC pattern isolates the Model, View, and Controller components, which makes the process loosely coupled built over the SysOperation framework. Depending on parameters, the controller can execute different service operations under four main execution modes. Regardless of which mode a service is running in, the code runs on a server. This makes the minimum number of round trips between server and client.
A standard approach to creating forms in Dynamics 365 for Finance and Operations is to build and store form objects in the AOT. It is possible to achieve a high level of complexity using this approach. However, in a number of cases, it is necessary to have forms created dynamically. In a standard Dynamics 365 for Finance and Operations application, we can see that application objects, such as the Table browser form, various lookups, or dialogs, are built dynamically. Even in Dynamics 365 for Finance and Operations, where we have a browser-based interface, every form or dialog opens in a browser only.
In this recipe, we will create a dynamic form. In order to show how flexible the form can be, we will replicate the layout of the existing Customer groups form located in the Accounts receivable module. The Customers form can be opened by navigating to Accounts receivable | Setup | Customers.
In Dynamics 365 for Finance and Operations, 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 365 for Finance and Operations controls; they are Group controls with their properties modified so that they look like splitters. Most of the multisection forms in Dynamics 365 for Finance and Operations already contain splitters.
In this recipe, in order 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. You can open this module by navigating to Cash and bank management | Setup | Bank group. From the following screenshot, you can see that it is not possible to control the size of each grid individually and that they are...
Often, people who are not familiar with computers and software tend to get lost among open application windows. The same can be applied to Dynamics 365 for Finance and Operations. Frequently, a user opens a form, clicks a button to open another one, and then goes back to the first one without closing the second form. Sometimes this happens intentionally, sometimes not, but the result is that the second form gets hidden behind the first one and the user starts wondering why it is not possible to close or edit the first form.
Although it is not best practice, sometimes 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 it is closed. In this recipe, we will make a modal window from the Create sales order form.
Carry out the following steps in order to complete this recipe:
SalesCreateOrder form in the project and set its Design property:Property | Value |
WindowType... |
