Forms are a predominant visual element in Dynamics NAV. There are 937 tables in the base NAV software and 1,820 forms that display information from those tables. Apart from learning how to create a form using the wizard, this article will not discuss the basic elements of form design. That information can be found in the C/SIDE Reference Guide and Development Coursework from Microsoft.
If you have not designed a form before, it is highly recommended that you acquaint yourself with forms first.
With NAV 2009, Microsoft released the RoleTailored client, or RTC. This was a huge change from the existing NAV product. In this release, Microsoft introduced the RTC as a second client or interface in addition to what is called the Classic client, or more traditional interface. While the future of NAV is definitely with the RTC, it is still important to understand what forms are and how they work, in order to support customers who might not upgrade to the latest version of the product.
Sometimes you don’t want to use an entire form to get user input. Dialog boxes are not a substitute for forms, but they work just fine for quick input.
Window.OPEN(‘Customer No: #1####################’);
Window.INPUT(1, CustomerNo);
Window.CLOSE;
IF Customer.GET(CustomerNo) THEN
MESSAGE(‘Customer Name: %1’, Customer.Name)
ELSE
MESSAGE(‘No customer found!);
The first line of code opens an input dialog window that looks like one shown in the following screenshot:
The next line lets the user input a value and stores it in the CustomerNo variable. The dialog window then closes and the result can be used later in code.
As you can tell from the input window, dialogs are much weaker than forms when it comes to functionality. You can’t do lookups, data validation, or anything other than basic text input. From a licensing aspect, forms are one of the cheapest objects to buy. They also don’t match the look and feel for the rest of the system. For these reasons it is almost always better to use a form than an input dialog, but it is important to know what you can do using dialogs.
You can always create a form manually, but using the Form Generation Wizard is a quick and painless way to create the skeleton.
The Form Generation Wizard allows you to tell the system what fields you want on the form and the format or order in which you want them to appear. NAV will then automatically place the fields on the form for you. There is no manual positioning of labels or textboxes; no creating tabs or list boxes. It is all done automatically.
The wizard will only create a basic form for you. If you need to create special functions or do any specific data validation, you will have to code that manually. A wizard is only designed to get you started, not to do anything advanced.
A great way to improve the user experience is to change the way text appears on the screen. This recipe will explore several options that are available to you.
Design the Customer List form and save it as a new object.
IF “Location Code” = ‘BLUE’ THEN
EXIT(16711680)
ELSE IF “Location Code” = ‘GREEN’ THEN
EXIT(65280)
ELSE IF “Location Code” = ‘RED’ THEN
EXIT(255)
ELSE IF “Location Code” = ‘YELLOW’ THEN
EXIT(65535)
EXIT(“Credit Limit (LCY)” > 1000);
CurrForm.Name.UPDATEFORECOLOR(GetColor);
CurrForm.Name.UPDATEFONTBOLD(GetBold);
The trigger that controls the appearance of text is the OnFormat trigger. The first function we use is UPDATEFORECOLOR. This method is found on every text field in a form. It takes one parameter—the color we want the text to be. In our example, we pass a function as the parameter and that function returns the color we should use.
UPDATEFONTBOLD works in a similar way. It takes a boolean parameter that tells the form whether or not to emphasize the text.
The resulting form will look similar to the one shown in the following screenshot:
The look and feel of a system is important for user satisfaction. Finding ways to make the information easier to understand, such as displaying the text in the same color as the warehouse location, can improve user understanding and decrease the time it takes to look up information.
That said, don’t go overboard. Having a form with multiple colors that have no direct relation to the data can be confusing. You don’t want to the user to have a “cheat sheet” of what everything means. If it takes longer than a couple of minutes to explain what certain characteristics mean and you can’t remember them an hour later, then you probably have gone too far. It also makes your upgrade-time to the RoleTailored client longer because display colors only have limited support.
You may want users to only add records when running a form from a setup location. This example will show you how to prevent users from adding or modifying values when only trying to look up a record.
This example will use the Salesperson/Purchasers form (14).
IF CurrForm.LOOKUPMODE THEN
CurrForm.EDITABLE := FALSE;
The code here is pretty self-explanatory. If the form is in lookup mode, it will not be editable.
The Lookup mode is a special mode in which forms can run. Essentially, when in lookup mode, the OK and Cancel buttons are displayed; when not in lookup mode, they are hidden. When using these buttons you can retrieve the selected value from the form. It is often a good idea to make forms uneditable in lookup mode, although you will find many forms in base NAV where this is not the case. When the purpose of running a form is only to retrieve a value, it is a good idea to make sure that the form is not editable to make sure those values are not accidentally changed.
Have you ever needed to make a form uneditable rather than just one field? This recipe will show you a quick and easy way to do it.
Create a list form based on the Customer table that displays the number and name of the customer. The Editable property of the form should be set to No.
CurrForm.EDITABLE := TRUE;
CurrForm.EDITABLE := FALSE;
When you click on a textbox its OnActivate trigger is executed. In our form, we have told the system to override the default Editable property when we click on the textbox. We set it to true so that the field becomes editable. In fact, the entire form becomes editable. We must make the entire form editable because that overrides the editable property of the controls on the form.
But when we click-off or tab-off of the field the OnDeactivate trigger fires. We then reset the form back to uneditable. Whenever the field is activated you can edit it, otherwise you cannot edit anything.
In the RoleTailored client there is no OnActivate or OnDeactivate trigger. You will have to do it the hard way, that is, by setting the Editable property on every field.
Further resources on this subject:
I remember deciding to pursue my first IT certification, the CompTIA A+. I had signed…
Key takeaways The transformer architecture has proved to be revolutionary in outperforming the classical RNN…
Once we learn how to deploy an Ubuntu server, how to manage users, and how…
Key-takeaways: Clean code isn’t just a nice thing to have or a luxury in software projects; it's a necessity. If we…
While developing a web application, or setting dynamic pages and meta tags we need to deal with…
Software architecture is one of the most discussed topics in the software industry today, and…