Preceding Posts In This Series

In Part 1 of this series of posts, we examined the underlying technologies behind RDLC reporting. In Part 2, we looked at the basic process of converting Dynamics NAV classic reports to an RDLC layout.

Since then, we’ve been examining specific issues you will encounter during the conversion process. In Converting Dynamics NAV Classic Reports To RDLC – Part 5 and Converting Dynamics NAV Classic Reports To RDLC – Part 6, we turned our attention to Report 5703 – Transfer Order as a sample conversion of a document report. We’ll now continue describing that conversion.

The Missing “Page” Label in the Upper Right Corner of the Header

At first glance, this appears to be a simple issue. However, there is more to it than meets the eye.

In the classic report, the line in the top right corner (i.e. the one that starts with “Transfer Order”) is a TextBox with a SourceExpr of “STRSUBSTNO(Text001,CopyText)”, where Text001 is a text constant set to “Transfer Order %1” and CopyText is a global variable set in the C/AL code of the CopyLoop data item to equal either “COPY” or blank.

Therefore, STRSUBSTNO(Text001,CopyText) = STRSUBSTR(‘Transfer Order %1’, ‘COPY’) = “Transfer Order COPY” in the case of a copy, and STRSUBSTR(‘Transfer Order %1’, ”) = “Transfer Order” where no copy is involved.

During the RDLC conversion process, the presence of this TextBox first results in a creation of a field in the RDLC data set. However, because this field must be used in the page header, where direct access to data fields is not allowed, the conversion process first creates an invisible Textbox to reference the field in the body of the RDLC report (the first small Textbox with the red font set in the far right portion of the body), then  creates a second Textbox in the header to reference the hidden Textbox by way of the VB expression: “=ReportItems!STRSUBSTNO_Text001_CopyText_.Value”.

This is shown in the following image of the RDLC layout:

1. TextBox in the classic report results in creation of an RDLC dataset field.
2. RDLC conversion process detects that the field must be used in a header, so it creates an invisible Textbox here in the body.
3. RDLC conversion process creates visible Textbox in the header, which uses an expression to reference the value of the hidden Textbox.

This is all standard behavior, but now let’s examine the TextBox that’s supposed to display the word “Page” followed by the page number.

It starts out quite similar to the “Transfer Order…” TextBox by using the SourceExpr “STRSUBSTNO(Text002,FORMAT(CurrReport.PAGENO))”, where Text002 is a text constant set to “Page %1”, and CurrReport.PAGENO is a function that allows you to set or retrieve the current page number.

This, in turn, does result in the creation of a field in the RDLC data set, called “STRSUBSTNO_Text002_FORMAT_CurrReport_PAGENO__”. But instead of treating this like the text value that is intended, the RDLC conversion process detects the attempt in the classic TextBox to use the CurrReport.PAGENO function, which is not supported in RDLC, and instead substitutes its own global page number function, “=Globals!PageNumber”, as shown below:

1. Dataset field is created, but it is not placed anywhere on the report.
2. Because of the presence of the CurrReport.PageNo function in the source TextBox, the conversion process creates a Textbox using the RDLC PageNumber function instead.

This not only results in the “Page” label being dropped. It also results in the display of the incorrect page number, which is supposed to reset to 1 for each new transfer order or copy thereof.

RDLC Conversion Behavior

Why spend so much time describing the page numbering mechanism in this report? First, because it explains the otherwise inexplicable difference in the conversion treatment of two classic TextBoxes that appear, on the surface, to be quite similar.

Second, to drive home a central point: the RDLC conversion process is not very sophisticated. To be safe, you should therefore expect the unexpected in the conversion of every single reporting object.

How do you fix the problem described in this post? The simple/crude answer is, you do what the RDLC conversion process should have done, i.e. use the standard approach, which is to create an invisible Textbox in the body of the RDLC report referencing the dataset field, then create a second Textbox in the page header to reference the value of the invisible Textbox.

However, there is a much more sophisticated solution to this problem (and others), which I’ll address later in this series of posts, but, for now, apply the simple solution to restore the proper page numbering.

Next Post

In our next post, we’ll continue with our repairs to the RDLC version of Report 5703 – Transfer Order, working our way from the top of the report  to the bottom.