Microsoft Dynamics NAV 2009: Designing Forms

Build better business applications with Microsoft Dynamics NAV 2009 with this book and eBook


Microsoft Dynamics NAV 2009 Programming Cookbook

Microsoft Dynamics NAV 2009 Programming Cookbook

Build better business applications with NAV

  • Write NAV programs to do everything from finding data in a table to integration with an instant messenger client
  • Develop your own .NET code to perform tasks that NAV cannot handle on its own
  • Work with SQL Server to create better integration between NAV and other systems
  • Learn to use the new features of the NAV 2009 Role Tailored Client
  • Easy-to-read recipes with detailed explanations and images
  • Maximize your learning with short tutorials that tell you exactly what you need to know without all of the fluff

        Read more about the Microsoft Dynamics NAV 2009 Programming Cookbook


(For more resources on Microsoft Dynamics, see here.)

In this article on designing forms, we will cover:

  • Obtaining input without a form
  • Using the Form Generation Wizard
  • Changing text appearance
  • Preventing editable lookup forms
  • Adding an editable field to a non-editable form


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.

Obtaining input without a form

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.

How to do it...

  1. Create a new codeunit from Object Designer.
  2. Add the following global variables:

  3. Add the following code to the OnRun trigger of the codeunit:

    Window.OPEN('Customer No: #1####################');
    Window.INPUT(1, CustomerNo);

    IF Customer.GET(CustomerNo) THEN
    MESSAGE('Customer Name: %1', Customer.Name)
    MESSAGE('No customer found!);

  4. Save and close the codeunit.

How it works...

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.

There's more...

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.

Using the Form Generation Wizard

You can always create a form manually, but using the Form Generation Wizard is a quick and painless way to create the skeleton.

How to do it...

  1. With the form selected in Object Designer click the New button.

  2. Choose the Customer table.
  3. Select Create a form using a wizard.
  4. Select Tabular-Type Form.
  5. Click OK.

  6. Use the arrow buttons between the two lists to add the No. and Name fields.

  7. Click on Finish.

How it works...

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.

There's more...

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.

Changing text appearance

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.

Getting ready

Design the Customer List form and save it as a new object.

How to do it...

  1. Design the copy of the Customer List form.
  2. Create a function named GetColor that returns an integer.
  3. Add the following code to the function:

    IF "Location Code" = 'BLUE' THEN
    ELSE IF "Location Code" = 'GREEN' THEN
    ELSE IF "Location Code" = 'RED' THEN
    ELSE IF "Location Code" = 'YELLOW' THEN

  4. Create a function named GetBold that returns a boolean value.
  5. Add the following code to the function:

    EXIT("Credit Limit (LCY)" > 1000);

  6. In the OnFormat trigger for the name column, add the following code:


  7. Save and close the form.

How it works...

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:

There's more...

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.

Preventing editable lookup forms

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.

Getting ready

This example will use the Salesperson/Purchasers form (14).

How to do it...

  1. Design the Salesperson/Purchasers form from Object Designer.
  2. In the OnOpen trigger for the form, add the following code:

    CurrForm.EDITABLE := FALSE;

  3. Save and close the form.

How it works...

The code here is pretty self-explanatory. If the form is in lookup mode, it will not be editable.

There's more...

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.

Adding an editable field to a non-editable form

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.

Getting ready

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.

How to do it...

  1. View the code for the Name column in the list form.
  2. In the OnActivate trigger, add the following code:

    CurrForm.EDITABLE := TRUE;

  3. In the OnDeactivate trigger add the following code:

    CurrForm.EDITABLE := FALSE;

  4. Save and close the form.

How it works...

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.


In this part of the article series we covered:

  • Obtaining input without a form
  • Using the Form Generation Wizard
  • Changing text appearance
  • Preventing editable lookup forms
  • Adding an editable field to a non-editable form

In the next article we will cover Creating a Matrix Form

Further resources on this subject:

Books to Consider

comments powered by Disqus

An Introduction to 3D Printing

Explore the future of manufacturing and design  - read our guide to 3d printing for free