All pages are made up of certain common components. The basic elements of a page object are the page triggers, page properties, controls, control triggers, and control properties.
The following screenshot shows the page triggers. The Help section Page and Action Triggers provides good general guidance to the event which causes each page trigger to fire. Note that the OnQueryClosePage trigger isn't related to any Query object action.
In general, according to best practices, we should minimize the C/AL code placed in Page triggers, putting the code in a Table or Field trigger or calling a Codeunit Library function instead. However, many standard pages include a modest amount of code supporting page specific filter or display functions. When we develop a new page, it's always a good idea to look for similar pages in the standard product and be guided by how those pages operate internally. Sometimes special display requirements result in complex code being required within a page. It is important that the code in a page be there for only managing the data display and not for data modification.
We will now look at the properties of the Radio Show List page we created earlier. The list of available page properties is the same for all page types. The values of these properties vary considerably from one page to another, even more from one page type to another. The following screenshot shows the Page - Properties screen of our Radio Show List page (Page 50000). This screen is accessed by opening Page 50000 in the Page Designer, highlighting the first empty line in the Controls list, and Clicking on the Properties icon (or Shift + F4 or View | Properties).
We can see that many of these properties are still in their default condition (they are not highlighted in bold). Following are the properties with which we are most likely to be concerned:
- ID: This is the unique object number of the page.
- Name: This is the unique name by which this page is referenced in C/AL code.
- Caption and CaptionML: This refers to the page name to be displayed, depending on the language option in use.
- Editable: This determines whether or not the controls in the page can be edited (assuming the table's Editable properties are also set to Yes). If this property is set to Yes, the page allows the individual the control to determine the appropriate Editable property value.
- Description: This is for internal documentation only.
- Permissions: This is used to instruct the system to allow the users of this page to have certain levels of access (r=read, i=insert, m=modify, d=delete) to the TableData in the specified table objects. For example, users of Page 499 (Available - Sales Lines) are allowed to only read or modify (Permissions for Sales Line = rm) the data in the Sales Line table.
- PageType: This specifies how this page will be displayed, using one of the available ten page types (RoleCenter, Card, List, ListPlus, Worksheet, ConfirmationDialog, StandardDialog, NavigatePage, CardPart, and ListPart).
- CardPageID: This is the ID of the Card page that should be launched when the user double-clicks on an entry in the list. This is only used on List pages.
- RefreshOnActivate: When set to Yes, This causes the page to refresh when the page is activated. This property is unsupported by the Web Client.
- PromotedActionCategoriesML: This allows the language to be changed for Promoted Action Categories from the default English (ENU) to another language, or to extend the number of Promoted Action Categories from the standard three options (New, Process, and Reports) to seven more categories. See the Help section How to: Define Promoted Action Categories Captions for the Ribbon.
- SourceTable: This is the name of the table to which the page is bound.
- SourceTableView: This can be utilized to automatically apply defined filters and/or open the page with a key other than the Primary Key.
- ShowFilter: This is set to No to have the Filter pane default to not visible. The user can still make the Filter pane visible.
- DelayedInsert: This delays the insertion of a new record until the user moves focus away from the new line being entered. If this value is no, then a new record will automatically be inserted into the table as soon as the primary key fields have been completed. This property is generally set to Yes when AutoSplitKey (see the second last point of this list) is set to Yes. It allows complex new data records to be entered with all the necessary fields completed.
- MultipleNewLines: When set to Yes, This supposedly allows the insertion of multiple new lines between existing records. However, it is set to No in the standard Order forms from Microsoft. This indicates that this property is no long active in NAV 2015.
- SaveValues: If set to Yes, This causes user-specific entered control values to be retained and redisplayed when the page is invoked another time.
- AutoSplitKey: This allows for the automatic assignment of a primary key, provided the last field in the primary key is an integer (there are rare exceptions to this, but we won't worry about them in this book). This feature enables each new entry to be assigned a key so it will remain sequenced in the table following the record appearing above it. Note that AutoSplitKey and DelayedInsert are generally used jointly. On a new entry at the end of a list of entries, the trailing integer portion of the primary key, often named Line No., is automatically incremented by 10,000 (the increment value cannot be changed). When a new entry is inserted between two previously existing entries, their current key-terminating integer values are summed and divided by two (hence the term AutoSplitKey) with the resultant value being used for the new entry key terminating integer value. Since 10,000 (the automatic increment) can only be divided by two and rounded to a non-zero integer result 13 times, only 13 new automatically numbered entries can be inserted between two previously recorded entries by the AutoSplitKey function.
- SourceTableTemporary: This allows use of a temporary table as the SourceTable for the page. This can be very useful where there is a need to display data based on the structure of a table, but not using the table data as it persists in the database. Examples of such an application are Page 634—Chart of Accounts Overview and Page 6510—Item Tracking Lines. Note that the temporary instance of the source table is empty when the page opens up, so our code must populate the temporary table in memory.
The Page Designer in NAV 2015 has a Page Preview tool which is very helpful in defining our control placement and action menu layout.
If we click on the Preview button while we have a page open in the Page Designer, a preview of that page's layout will display. The controls and actions are not active in the preview (this is display only), but we can display all the ribbon tabs and their controls.
The Preview screen is interactively linked to the Page Designer and its subordinate Action Designer. When we click on a control line in the Page Designer or an Action line in the Action Designer, the Page Preview highlights the generated object. Or when we click on a control or action displayed in the previewed page, the corresponding line in the Page Designer or Action Designer is highlighted. An example of a highlighted control is shown in the following partial page screenshot:
In the following screenshot, an action is highlighted in the Preview page:
One of the attributes of an object oriented system is the inheritance of properties. While NAV is object-based rather than object-oriented, the properties that affect data validation are inherited. Properties such as decimal formatting are also inherited. If a property is explicitly defined in the table, it cannot be less restrictively defined elsewhere.
Controls that are bound to a table field will inherit the settings of the properties that are common to both the field definition and the control definition. This basic concept applies to inheritance of data properties – beginning from fields in tables to pages and reports, and then from pages and reports to controls within the pages and reports. Inherited property settings that involve data validation cannot be overridden, but all others can be changed. This is another example of why it is generally best to define the properties in the table, for consistency and ease of maintenance, rather than defining them for each instance of use in a page or a report.