Modifying the System using Microsoft Dynamics Nav 2009: Part 2

David Roys

August 2009

Customizing pages

Pages are the RoleTailored client's equivalent of forms, and are the building blocks of the RoleTailored user interface. They are used primarily to display information from the database and to allow data entry, but we can use them simply to put anything we wish on screen for the user to interact with.

To create a page, in Object Designer select Pages, then click the New button. The New Page form will assist you through the creation process:

Microsoft Dynamics NAV 2009

Page properties

Unlike the New Form dialog, here you can only choose the source table and the type of page; but as soon as you make your choice, a blank Page Designer is shown, with only two properties filled out: SourceTable and PageType. Most page properties are called exactly the same and exhibit the same behavior as form properties, but there are four additional ones:




Specifies the type of the page. Types affect the behavior of pages, and we will discuss page types in more detail later on.


Declares the multi-language text label that will be displayed on the page before any other user interface element. It only has effect on ConfirmationDialog type forms.


Defines the card form that is used to display, edit, or create records of the type that is displayed in a list. For example, in Customer List, this property defines that Customer Card is invoked every time a user calls the Edit, View, or New action. This property affects only list type forms.


Specifies whether links functionality will be available for this page or not.

Page types

The most important of these properties is PageType, because it defines the behavior of the form when displayed in the RoleTailored client. There are exactly ten types of pages: Card, List, RoleCenter, CardPart, ListPart, Document, Worksheet, ListPlus, ConfirmationDialog and NavigatePage.

Let's take a closer look at their purpose, functionality, and anatomy.


Similar to the card form, this type of page displays information about one record of a single table, such as one customer, one vendor, or one item. Typical examples of a card page are 21 Customer Card, or 30 Item Card.

The following is what a typical page looks like:

Microsoft Dynamics NAV 2009

At the top of the page there are actions. Actions can be grouped into menus, or into toolbars.

The majority of the screen is used for information display and entry. The left part of the screen is occupied with a ContentArea, which consists of groups of fields called FastTabs. Values of fields in FastTabs are typically taken from a single record of a table.

The right part of the screen is occupied by the FactBoxArea, which contains several FactBoxes.


Similar to the list form, List pages display multiple records from the same table at once, such as a list of customers, list of vendors, or list of items. Typical examples are 22 Customer List, or 27 Vendor List.

This is what a List page looks like:

Microsoft Dynamics NAV 2009

It has exactly the same elements as a card page, except its ContentArea is consumed by a single repeater group, which lists all information in a table.


Pages of this type are used as home screens for different roles. They consist of different parts, and are used to provide quick access to the functionality most used by a user role, as well as the most relevant information, all at a glance. Examples of RoleCenter pages are 9005 Sales Manager Role Center and 9010 Production Planner Role Center.

The following is what a RoleCenter looks like:

Microsoft Dynamics NAV 2009

It consists of groups displayed as vertical columns. In each group it is possible to have several page parts, such as Activities, My Items, and many more.


CardPart pages are card pages that aren't used standalone, but come as parts on other pages, such as Card, List, or RoleCenter pages. Various FactBoxes, such as 9082 Customer Statistics or 9092 Approval Factbox, are typical examples of CardPart pages. Most elements of a RoleCenter, as well as most FactBoxes are actually CardPart (or ListPart) pages. Here is an example of a CardPart:

Microsoft Dynamics NAV 2009

CardPart pages typically consist of several groups, which are rendered in various ways, depending on the type of elements displayed. The CardPart shown consists of three CueGroups.


ListPart pages are list pages intended for inclusion as parts of other types of pages. Pages such as 47 Sales Invoice Subform or 9150 My Customers are examples of ListPart pages. Most of the list part pages are simply sub-pages of other pages, but often ListParts find their way into RoleCenter pages or FactBox areas as well.

Here goes a ListPart:

Microsoft Dynamics NAV 2009

As obvious as it is, all list parts consist of columns of fields.


Document pages are combinations of card and list types, and contain several groups of header information and typically one ListPart page with lines information. Information contained in header and lines of a Document page represents an indivisible entity (for example an invoice consists of both header and lines). Take a look at page 43 Sales Invoice or 99000831 Released Production Order to get a feel for document pages.

The following is a document page:

Microsoft Dynamics NAV 2009

If at first it doesn't look much different from a typical card page, take a closer look. One of its FastTabs is actually a ListPart page.


Worksheet forms are used for various journals, such as 39 General Journal or 40 Item Journal, and they typically comprise a filter, lines, and a summary footer.

This is what a good Worksheet page looks like:

Microsoft Dynamics NAV 2009

The elements of a Worksheet page are a single filter field used to choose batches (groups of lines of a worksheet that will be processed as a single transaction), lines, and a footer, which typically gives summary information about the worksheet lines.


This is a hybrid of list and card types, but different from document type. It contains header information and lines information; however, the lines don't belong to the header, they are only related to it. Good examples of ListPlus pages are 397 Sales Invoice Statistics or 5091 Segment.

The following is a ListPlus:

Microsoft Dynamics NAV 2009

If it reminds you of a Document, it is so because it is similar. It contains exactly the same types of elements, and is rendered similarly, and the difference is purely technical. A document represents a single entity while a ListPlus contains information collected from various entities.


Pages of this type are used for important interruptions of user actions, when the application needs an extra confirmation from the user before the action can be completed. These pages usually contain information that will aid the user in deciding the course of action. Typical examples of ConfirmationDialog pages are pages 342 Check Availability or 343 Check Credit Limit.

This is a typical ConfirmationDialog:

Microsoft Dynamics NAV 2009

Notice the text above the FastTab: it comes from the InformationalTextML property, which can be defined on any type of page, but only has effect on pages of type ConfirmationDialog.


For pages of this type, groups aren't displayed as FastTabs, but as normal tabs (although on the bottom of the page). The most obvious example is of course page 344 Navigate, but as tabs can be made visible or invisible interchangeably, this type of page is very useful for wizards, such as 5077 Create Interaction or 5126 Create Opportunity.

Microsoft Dynamics NAV 2009

While tabs didn't find their way into card or document pages, they got their upside-down spot in NavigatePage pages. They work exactly the same way that page control works in form objects.

Page Designer

To get a feeling of how a simple page is designed, in Object Designer locate the page 5714 Responsibility Center Card and click the Design button:

Microsoft Dynamics NAV 2009

Unlike Form Designer, which we saw earlier, here we can declare user interface elements (controls), but can't specify exactly how or where they will be positioned on screen.

To create a new control, select the first empty line and simply start typing something into the Name or Caption column. These two properties have exactly the same meaning as anywhere else in the system. Important properties you must set for page controls are Type, SubType, and SourceExpr.




Defines the general behavior of the control. Each control belongs to one of the four types: Container, Group, Field, or Part.


For each type, there are several subtypes, which further modify the control and its behavior.


For controls of type Field, this property defines the source from which the control's value is taken.

Let's take a closer look at types and their respective subtypes.


At the base of every page there is a container, and every page must have a container defined as its topmost element. The container is used to define the general behavior of the page.

There are three subtypes of containers:

  • ContentArea: most common container subtype, used for most page types. If a page is not a FactBox or a RoleCenter page, then its topmost container must be of type ContentArea.
  • FactBoxArea: containers of this type contain page parts of FactBox type, and place them in the FactBox pane of the page.
  • RoleCenterArea: used by pages of type RoleCenter, these containers group page parts into vertical columns.

Don't define two containers of the same type per page. A page must contain exactly one ContentArea or RoleCenter area, and up to one FactBoxArea. Any other containers beyond these will be ignored and won't be rendered.


Groups are used to group other controls together in several different ways. Group subtype determines how exactly the group is rendered in the RoleTailored client.

There are four group subtypes:

  • Group: groups fields into FastTabs, for easier navigation and to reduce clutter on screen. This subtype is typically used on card type pages.
  • Repeater: groups fields into tabular lists, typically on list or ListPart pages.
  • CueGroup: displays fields as visual cues, instead of as normal field controls.
  • FixedLayout: displays field values as non-editable labels, without their field captions. Typically used with worksheet type pages.

Group subtype affects several other aspects of the RoleTailored client renderer. For example, it determines the type of icon that RoleCenter will display in the upper-left corner of a page part. If a part page contains a CueGroup, the icon will display a pile of papers, while for other group subtypes it will display a single document.

For other page types groups also have specific behavior. For example, in pages of type NavigatePage, groups are rendered as tabs, instead of as FastTabs. For PageCards, groups are displayed as labels printed in bold, while ListCard pages will ignore any groups other than Repeaters.

Cue groups specialty: Cue groups don't just look great on screen. They also integrate neatly into the Home menu when used on Role Center pages. When a field displayed in a cue group uses as its drill-down page a page that has been placed as an action into the Home menu, then a filter is added to that Home menu action, which will inherit display value and drill-down functionality from the cue group field. Thus, cue groups effectively remain accessible at all times through Home menu actions. Take a look at these; they all come from cue groups in the Order Processor role center:

Microsoft Dynamics NAV 2009


The most common element of all pages is field, and most of the pages contain plenty of these. Fields are used to display actual values from the database, and to allow entry of new values. Fields can display values taken from table fields, C/AL variables, functions, or text constants.

How exactly the field will be displayed is determined by:

  • Data type of the value associated with the field: Every data type will render a particular user interface control. Code, text, and numeric fields are rendered as text boxes, options are rendered as combo boxes, boolean values display checkboxes, and date values come with the date picker control.
  • TableRelation property: If a field is related to another table as a lookup field, it will display a drop-down menu similar to a combo box, which allows looking up values from another table. If a field is a SIFT field, it will be displayed as a hyperlink, which will allow drilling down to actual values used for calculation of the value displayed in the SIFT field.
  • Group subtype: Fields in Group subtypes will be rendered with their captions to the left of the field control; fields in CueGroup are rendered as visual cues (stacks of documents); fields in Repeaters will be rendered as columns of tables; and fields belonging to FixedLayout groups will be displayed as read-only labels without caption.
  • ExtendedDatatype property: If defined on a field, this property determines additional functionality of the field. Values of Phone No., URL, and E-Mail will display an icon button, which will launch a phone caller application, a web browser, or an e-mail client respectively, while Ratio fields will be displayed as progress bars.


The RoleTailored client allows you to embed pages and other objects, such as charts, as parts of other pages. This can be achieved through controls of type Part. It is only possible to embed pages of type CardPart and ListPart.

Parts don't have subtypes, but their behavior is controlled by an important property: PartType. It can have one of the following values: Page, System, or Chart.

Page parts

The default value of the PartType property is Page, and it's for reason: the most common type of parts is other pages. It is possible to embed CardPart or ListPart pages only, but you have a lot of flexibility with them to define whatever functionality you want to see embedded.

When you specify Page as PartType, you must also define the PagePartID property, which must contain the ID of the page object you want to embed.

System parts

Other than user-defined parts, there are system provided parts, which give access to useful functionality and information.

For system parts it is necessary to specify, SystemPartID property, which is really a drop-down list of the following parts:

  • Outlook: displays the Outlook integration part, which provides information about pending items, such as e-mail messages, calendar entries, or tasks.
  • Notes: displays the notes linked to the currently selected entity.
  • MyNotes: displays notifications other users sent to the user using Notes functionality.
  • RecordLinks: displays the links related to the currently selected entity.

Chart parts

A particularly eye-candy feature of Microsoft Dynamics NAV 2009 is charts, a special type of parts, which can be included on any RoleCenter page without any declaration, or on other types of pages by declaring them through a Part property of type Chart.

There is a smorgasbord of system-provided charts, which cover most application areas from accounting to manufacturing. If you are unhappy with these, you can create and import your own. Chart definitions are stored in the system table 2000000078 Chart, where they can be imported or exported as XML definitions using the Charts form or page. You can find Charts in the Departments page (or navigation pane if you are using the Classic client) under Administration | Application Setup | RoleTailored Client.

Positioning controls

There is little you can do about specifying exactly where a control will be rendered in the page. Properties well known from forms and reports, such as XPos and YPos, simply don't exist for pages. With this, the RoleTailored client is somewhat stubborn, so the best you can do is get to know how it works, then play along with these rules.

Generally, the objects are rendered in that order in which they are declared. Depending on page type, groups are arranged horizontally or vertically, according to their order in Page Designer. If you have a card page, and you want something to display to the right, the only option you have is to place it into a FactBoxArea.

If you are unhappy with the order of controls, you can change it by moving them up or down, using the up or down buttons ( and ). Be careful when rearranging groups, because moving a group up or down will move the group control only. Fields or parts belonging to that group will stay in the same place, and you will have to move each control individually. Furthermore, moving groups up or down will typically disrupt their indentation, so you will probably need to fix it using the indent buttons ( and ).

Fields in FastTabs are always arranged in two columns, in somewhat annoying fashion: the number of fields is divided by two, with equal number of fields displayed in each column. It's impossible to have a FastTab with only one column (unless it sports a single field), or with five controls in the left column and two controls in the right one.

Spur some action

Other than controls for displaying and entering information, pages also contain actions. Actions are used to call other objects, such as pages or reports, or to execute application logic, such as posting procedures.

Most of the pages contain actions, which are displayed in the menu bar and the actions pane. This is how actions are organized for page 21 Customer Card:

Microsoft Dynamics NAV 2009

Actions are grouped into three menus (Actions, Related Information, and Reports), and three action categories (New, Process, and Reports). Menus look and function much like the menu buttons in the Classic client, while action categories are a new concept for Microsoft Dynamics NAV users. Functionally, they resemble ribbon groups in Microsoft Office 2007 applications.

To def´╗┐ine actions for a page, in Page Designer scroll down to the first empty line, then select Actions from the View menu.

It is possible to define actions on non-empty lines; however, these actions only have effect in specific cases, for example on CueGroup controls. In most other cases, the RoleTailored client will simply ignore them.

Microsoft Dynamics NAV 2009

Designing actions is as simple as designing page controls, because the Action Designer employs the same logic as Page Designer. Indenting and moving of actions works exactly the same way as with page controls, and basic properties used to define actions are called exactly the same way as with page controls.

Luckily, it is possible to use the magic of copy-and-paste to copy actions to the clipboard, then paste them into another object's Action Designer. This is something that was never possible for menu items of menu button controls in forms.

There are four types of actions that can be defined using the Type property: ActionContainer, ActionGroup, Action, and Separator.


Yes, you've got it right: ActionContainers contain actions. Every action must belong to a container, and there are several types of containers you can use. Each container type is defined by the SubType property, which can have one of the following values:

  • NewDocumentItems: Actions in this container are placed into the New Document submenu of the Actions menu.
  • ActionItems: Actions in this container are placed into the Actions menu below the Links action.

This is how NewDocumentAction and ActionItems actions are placed into the Actions menu:

Microsoft Dynamics NAV 2009

  • RelatedInformation: Actions in this container are placed into the Related Information menu.

Microsoft Dynamics NAV 2009

  • Reports: Actions in this container are placed into the Reports menu.

Microsoft Dynamics NAV 2009

  • HomeItems: Actions in this container are placed into the Home menu of the Role Center. Understandably, this container is only relevant for RoleCenter pages, and other pages ignore any actions placed in this container.
  • ActivityButtons: Actions in this container are placed in the navigation pane just between the Home button and the Departments button.

This is how HomeItems and ActivityButtons are placed:

Microsoft Dynamics NAV 2009


You can use ActionGroups to group actions into meaningful sets. How exactly a group will behave depends on the ActionContainer subtype.

For NewDocuments, ActionItems, RelatedInformation, and Reports container subtypes, each group will be displayed as a submenu:

Microsoft Dynamics NAV 2009

In this example, Customer, Sales, Issued Documents, and Dimensions are actions of type ActionGroup.

For the HomeItems container, groups are ignored, and all actions are rendered in one flat list.

Groups in an ActivityButtons container are displayed as buttons in the navigation pane:

Microsoft Dynamics NAV 2009

In the screenshot shown, Posted Documents and Administration are declared as actions of type ActionGroup.


All of these define just the skeleton—actions of type Action constitute the fleshy part of the page navigation. For the sake of clarity, we will simply call them actions (to avoid clumsy, but accurate term actions of type Action).

Actions are used to call pages or reports, or to execute any C/AL logic that might be defined behind them. Most navigation needs can be fulfilled without any code, though, by setting properties:




Specifies in which state the page invoked by this action will be open. This can be View, Edit, or Create. View will display the page as read-only; Edit will make it editable; and Create will display an editable page with all fields emptied and ready to insert the new record.


Specifies the icon that will be displayed with the caption. There are hundreds of icons, each of which is referred to using a textual identifier.


Specifies whether an action is promoted to one of the action categories, for better visibility and accessibility on the screen.


Specifies into which action category in the action pane this action will be promoted. Possible choices are New, Process, and Reports.


If set to Yes, this will make the promoted action button big.


Specifies whether the action caption is displayed with an ellipsis (...) appended, indicating that clicking this action will require further input before the action is completed.


Defines the keyboard shortcut that can be pressed to invoke the action directly, without clicking on it with the mouse.


Defines which object will be called when the action is invoked. You can run pages, reports, codeunits, and XMLports.


Specifies any keys, sort order, or filters that will be applied to the page specified in RunObject when it is run (applies only to page objects).


Specifies the link between the calling page and called page (applies only to page objects). It works as a dynamic filter, because it enables filtering another page based on values of the active record in current page.

There are two major concepts that rely on setting these properties: promotion, and object running.

Action promotion

Actions are typically displayed in menus; however, you can promote the most used actions to make them more accessible and readily visible to your users. Promoted actions are displayed both in menus and in the action pane, in one of the three possible categories.

These are the promoted actions for Transfer Order:

Microsoft Dynamics NAV 2009

To promote an action, you need to set its Promoted property to Yes, and choose the category into which it is promoted the (default is New). If you need to make promoted items very prominent, you can set their PromotedIsBig property to Yes, to make them really big in the action pane.

Promotion category doesn't have anything to do with the ActionContainer type, and you can promote actions from the NewDocumentItems container into categories other than New, or actions from a non-NewDocumentItems container into the New category.

Object running

Actions are used to execute things, and there are only two ways to make them do so: to make them run objects, or to make them call C/AL code by utilizing their OnAction triggers. The former is easy, because it requires no knowledge of C/AL and is intended for simple navigation, such as opening specific entities from a list of entities, or running a report. The latter can be as simple as writing a single line of code, or as complex as hundreds of lines of very complicated business logic.

Never put extensive business logic directly into the OnAction trigger. Instead, embed the business logic into a separate function, preferably of a codeunit (a concept know as abstraction), and then call this function. This will make your code reusable, and safe from inadvertent deletions.

To specify which object will be run when the action is clicked, you need to define its RunObject property. You can do it by manually typing the object's Type and ID, or Type and Name (this is one of those situations where the Name property matters outside of C/AL variable declarations). For example, to call Customer Card, you simply type Page 21, or Page Customer Card.

Another possibility is to select the RunObject property, then press F6 or click the Assist button, then choose from the list of all possible objects. After a while you'll catch yourself simply typing the object ID's from memory like a real pro.

If you are calling pages, you may want to specify sort order or any filters that will be applied to these objects. You can achieve this by using the RunFormView property. You can either type in the view syntax manually, or you can press F6 to invoke the Table View editor, which will make your chore considerably easier:

Microsoft Dynamics NAV 2009

Form Transformation tool

Now you have seen how much work it is to define proper and good looking forms, and how much effort it is to create decent pages; effectively this is twice as much effort to create what's fundamentally the same thing: a user interface. Having forms and pages as separate objects is a major pain for developers. Or at least it would be if there weren't the Form Transformation tool.

As its name suggests, it is used to convert forms to pages. As you have seen, there are many differences between forms and pages, but there are many similarities as well. These similarities are the basis for the Form Transformation tool: it makes use of them to make it possible to convert almost every form to a page of mostly the same functional value.

>> Continue Reading Modifying the System using Microsoft Dynamics Nav 2009: Part 3


[ 1 | 2 | 3 ]

You've been reading an excerpt of:

Implementing Microsoft Dynamics NAV 2009

Explore Title