Earlier, we reviewed a list of the components of a Report object. Now, we're going to review detailed information about each of these components. Our goal here is to understand how the pieces of the report puzzle fit together.
The C/SIDE RD Report Properties are shown in the following screenshot. Some of these properties have essentially the same purpose as similarly named properties in pages and other objects:
The properties in the preceding image are defined as follows:
- ID: The unique report object number.
- Name: The name by which this report is referred to within the C/AL code.
- Caption: The name that is displayed for this report; Caption defaults to Name.
- CaptionML: The Caption translation for a defined alternative language.
- Description: For internal documentation.
- UseRequestPage: Yes or No, controlling whether or not the report will begin with Request Page for the user parameters to be entered.
- UseSystemPrinter: Determines whether the default printer for the report should be the defined system printer, or whether NAV should check for a setup-defined User/Report printer definition. More on User/Report printer setup can be found in the NAV application help.
- EnableExternalImages: If Yes, this allows links to external (non-embedded) images on the report. Such images can be outside the NAV database.
- EnableHyperLinks: If Yes, this allows links to other URLs, including other reports or to pages.
- EnableExternalAssemblies: If
Yes, this allows the use of external custom functions as part of the report. - ProcessingOnly: Set to
Yeswhen the report object is being used only to process data and no reporting output is to be generated. If this property is set to Yes, then it overrides any other property selections that would apply in a report-generating situation. - ShowPrintStatus: If this property is set to
Yesand the ProcessingOnly property is set toNo, then a Report Progress window, including a Cancel button, is displayed. When ProcessingOnly is set toYes, if we want a Report Progress Window, we must create our own dialog box. - TransactionType: This can be in one of the four basic options: Browse, Snapshot, UpdateNoLocks, and Update. These control the record locking behavior to be applied in this report. The default is UpdateNoLocks. This property is generally only used by advanced developers.
- Permissions: This provides report-specific setting of permissions, which are the rights to access data, subdivided into Read, Insert, Modify, and Delete. This allows the developer to define report and processing permissions that override the user-by-user permissions security setup.
- PaperSourceFirstPage, PaperSourceDefaultPage, and PaperSourceLastPage: All allow the choice of the paper source tray based on information in the
fin.stxfile (fin.stx is an installation file that contains the active language messages and reserved words in addition to some system control parameters that are defined by Microsoft and are not modifiable by anyone else). - PreviewMode: Specifies the choice of the default Normal or PrintLayout, causing the report to open up in either the interactive view allowing manipulation or in a fixed format on a printer.
- DefaultLayout: Specifies whether the report will use either the Word or the RDLC layout.
- WordMergeDataItem: Defines the table on which the outside processing loop will occur for a Word layout (equivalent to the effect of the first DataItem on an RDLC layout).
The SSRB Properties Window is docked by default on the right-hand side of the screen (as with most SSRB windows, it can be redocked, hidden, or float).
By highlighting various report elements (individual cells, rows, columns, and so on), we can choose which set of properties we want to access, those of the whole Report, Body, Tablix, or individual Text Boxes. Once we have chosen the desired set of properties, we can access these properties in one of two ways. The obvious way is through the window that opens up when we choose which control properties to display. The following screenshot shows the properties of Text Box with the Font properties highlighted and expanded.
The Font properties are the properties most often accessed to change the appearance of a report layout, although a variety of other field formatting properties are also utilized:
Another way to access property details is to highlight the element of interest, right click and select the Properties option for that element. This opens up a control-specific Properties window, which includes a menu of choices of property categories to access. In the following image, Text Box Properties were opened and the Font properties accessed for display:
Some may feel it's easier to find and change all the properties options here. This applies to Report-level properties controlling macro elements, such as Paper Orientation, as well as to control-level properties controlling micro elements such as font size. Report-level properties also include the facility to include expressions that affect the behavior or controls. The expression shown in the following image is generated by NAV to support C/SIDE field formatting properties such as Blank When Zero:
The following screenshot shows the C/SIDE RD Report triggers available in a report:
Report Trigger can be explained as follows:
- Documentation(): Documentation is technically not a trigger, since it can hold no executable code. It will contain whatever documentation we care to put in there. There are no format restrictions.
- OnInitReport(): Executes once when the report is opened.
- OnPreReport(): Executes once after Request Page completes. All the DataItem processing follows this trigger.
- OnPostReport(): If the report is completed normally, this trigger executes once at the end of all of the other report processing. All the DataItem processing precedes this trigger.
The Request Page properties are a subset of the Page properties that are covered in detail in Chapter 4, Pages – The Interactive Interface. Usually, most of these properties are not changed simply because the extra capability is not needed. An exception is the SaveValues property, which, when set to Yes, causes the entered values to be retained and redisplayed when the page is invoked another time. A screenshot of the Request Page properties follows:
Request Pages have a full complement of triggers, thus allowing for complex pre-report processing logic. Because of their comparatively simplistic nature, Request Pages seldom need to take advantage of these trigger capabilities.
The following screenshot shows the properties of DataItem:
The following are descriptions of frequently used DataItems properties:
- Indentation: This shows the position of the referenced DataItem in the hierarchical structure of the report. A value of 0 (zero) indicates that this DataItem is at the top of the hierarchy. Any other value indicates that the subject DataItem is subordinate to (that is nested within) the preceding DataItem.
- DataItemTable: This is the name of the NAV table assigned to this DataItem.
- DataItemTableView: This is the definition of the fixed limits to be applied to the DataItem (the key, ascending or descending sequence, and that filters that can be applied to this field).
Note
If we don't define a key, then the users can choose a key to control the data sequence to be used during processing. If we do define a key in the DataItem properties and in the ReqFiltgerFields property, we do not specify any Filter Field names to be displayed; this DataItem will not have FastTab displayed as part of Request Page. This will stop the user from filtering this DataItem, unless we provide the capability in the C/AL code.
- DataItemLinkReference: This names the parent DataItem to which this DataItem is linked.
- DataItemLink: This identifies the field-to-field linkage between this DataItem and its parent DataItem. This linkage acts as a filter because only those records in this table will be processed that have a value that matches with the linked field in the parent data item. If no field linkage filter is defined, all the records in the child table will be processed for each record processed in its parent table.
- ReqFilterFields: This property allows us to choose certain fields to be named in Report Request Page, to make it easier for the user to access them as filter fields. As long as Report Request Page is activated for DataItem, the user can choose any available field in the table for filtering, irrespective of what is specified here.
- CalcFields: This names FlowFields that are to be calculated for each record processed. Because FlowFields do not contain data, they have to be calculated to be used. When FlowField is displayed on a page, NAV automatically does the calculation. When FlowField is to be used in a report, we must instigate the calculation. This can either be done here in this property or explicitly within the C/AL code.
- MaxIteration: This can be used to limit the number of iterations that the report will make through this DataItem. For example, we would set this to 7 for processing with the virtual Date table to process one week's data.
- PrintOnlyIfDetail: This should only be used if this DataItem has a child DataItem, that is, DataItem indented/nested below it. If PrintOnlyIfDetail is
Yes, then controls associated with this DataItem will only print when data is processed for the child DataItem. - Temporary: Specifies that a temporary table is supplying the dataset to populate the columns for this DataItem.
Each DataItem has the following triggers available:
DataItem triggers are where most of the flow logic is placed for a report. Developer-defined functions may be freely added, but generally, they will be called from within these three triggers.
- OnPreDataItem() is the logical place for any preprocessing to take place that can't be handled in Report or DataItem properties or in the two report preprocessing triggers
- OnAfterGetRecord() is the data "read + process loop". The code placed here has full access to the data of each record, one record at a time. This trigger is repetitively processed until the logical end of table is reached for this DataItem. This is where we would typically access data in related tables. This trigger is represented on our report Data Flow diagram as any one of the boxes labeled DataItem Processing Loop.
- OnPostDataItem() executes after all the records in this DataItem are processed, unless the report is terminated by means of a User Cancel or by execution of a C/AL
BREAKorQUITfunction, or by an error.