Working with Form Logic and Frameworks

In this chapter, we will get straight into writing code. The recipes chosen for this chapter are common tasks that will be used on many development projects.

As we progress through this chapter, references to code placement will be made. Code placement is critical to a maintainable and extendable solution. We will see that code can be written on the form, in a class, or in a table. The rule of thumb here is that we must place code as low in the stack as possible. If we write code on a form, that code is only available to that form and cannot be reused. This is fine when we are hiding a button, but data (validation and other data-specific code) logic usually belongs to a table. As the code on the form or table gets more complicated, the code should be moved to a class.

The SalesTable form and table is an example. In this case, table events...

Technical requirement

You can find the code files for this chapter on GitHub at https://github.com/PacktPublishing/Extending-Microsoft-Dynamics-365-Finance-and-Supply-Chain-Management-Cookbook-Second-Edition/blob/master/Chapter%204.axpp.

Creating a table handler class

Although we can write code directly onto the table, this can limit the extendability of the code, should its complexity increase. In later chapters, we will refactor this class so that it uses the SysExtension pattern. This is where the actual class is constructed in a factory method based on metadata. This would be very difficult should the code be on the table, as we need to change all of the code that calls the methods on the table.

We will, therefore, create a table handler class and move the existing instance methods to this class.

How to do it...

To create the table handler class, follow these steps:

1. Create a new class named ConVMSVehicleServiceTableType.

2. We will construct the instance...

Creating a form handler class

Technically, form handler classes are not required as all code can be added directly to a form. The problem with this is that, as form logic gets more logic, it becomes harder to read as the purpose of each method becomes less obvious and less easy to maintain as the amount of code increases. Code placed directly on a form is usually much harder to use by third parties and the code is not reusable.

For this reason, we would usually create a form handler class to handle user interface logic on order entry style forms. These forms usually need a create form in order to make order creation easier. The form handler will act as a way to pass data between the main order entry form and the create form.

Form handlers were used to handle number sequences, but the pattern has changed now as number sequence handling is more logically handled on the form, or...

Hooking up a number sequence

The number sequence framework is used on most Details Master (Main tables) and Details Transaction (Worksheet tables) forms; for example, the sales order number is generated through a number sequence. These used to be hooked up to the form directly, or in the form handler class, which made sense previously as user interface events (new record, delete record, abandon a new record, and so on) would need to be handled. The problem with this is that if we have two forms that handle the same table, we may need to write the code twice.

The new pattern is that it is handled on the table or table handler, but called from the form or form handler class. First, we will create a class that defines our number sequences, and then we'll write the code to handle them.

...

Creating a create dialog for details transaction forms

In this recipe, we will create a dialog that brings together the key information needed in order to create the header fields on our details transaction (order entry) form. This is often different than the fields on the header portion of the lines view of the form. This is because it is common that some fields that are entered at the point of creation aren't needed after their creation.

Getting ready

For this recipe, we need to have created a details transaction style form. This was covered in Chapter 3, Creating the User Interface, in the Creating a details transaction (order entry) form recipe.

...

Updating form controls at runtime

Sometimes, the form needs to be adjusted beyond allowing the user to edit a record or field or allowing a button to be pressed. Let's say we wish to add custom fields, where the label is decided by information only known at runtime. The example that will be used in this recipe is intended to be seen as a starting point, showing a way in which we can dynamically control the form.

Getting ready

Ideally, we should have a form with a grid view, such as the ConVMSVehicleServiceTable form.

How to do it...

To iterate through a container...