Sooner than expected, the next step in NAV reporting is available and I have called it Wordlayout+, because it extends the standard Wordlayout capabilities of NAV 2016. Especially the following features have been implemented:
- Nested Groups (Customer -> SalesHeader -> SalesLines, e. g.)
- Improved image handling (empty image is displayed as empyt, image size is retained)
- Manual line breaks within plain text controls (“Allow multiple paragraphs” works now)
- Repeating Sections around arbitrary paragraphs, table rows or even whole tables (standard NAV works only for one table row)
- Formatted output for Rich Text Controls works now
- Optionally blank zero values
How is it implemented?
The implementation is as close to standard NAV as possible. The investigations in the previous post https://massivedynamicsblog.wordpress.com/2016/09/08/wordlayout-revisited/ already suggest the most elegant implementation. In fact, only one Codeunit (9651) has to be modified slightly and a new server-based AddIn has to be copied to the server AddIn folder. Technically speaking, the standard WordReportManager AddIn with its method MergeCustomXML has been replaced by a new AddIn with the above features.
How does it work?
In a first step, the output of the REPORT.SAVEASXML function is converted to CustomXMLPart-format via an XSL-Transformation. This transformation also converts empty text elements to a space character and empty image elements (whose names start with “img”) to a small white one-pixel-image. This is done in order to avoid the standard word placeholder text/image for empty content controls (“Click here to enter text.”, etc.). Furthermore, for elements whose names start with “b0”, a “0” (zero) is automatically blanked to a space and the formatting of decimal values is done with respect to the decimalformatter attribute, given in the NAV XML data (it would be nice, if there were also a blankzero attribute). After this transformation, the custom xml part is replaced in the wordlayout template. That’s all.
When you open the resulting document in word, the content controls are filled with the xml data automatically by the word application. All content controls are retained. In standard NAV functionality, the content controls are removed and only their content is retained. With the new feature of retaining content controls, it is now possible to edit the word document and import the custom xml part back into NAV, because any change of a content control is immediately saved in the custom xml part of the word document.
What is now possible?
In order to demonstrate the new capabilites, I created a Wordlayout for the standard report 108 “Customer – Order Detail” as close as possible to the standard RDLC layout. You can download the slightly modified report object together with a fully functional demo version of Wordlayout+ here:
In the print result, there is hardly any difference between RDLC and Wordlayout+. I have relinquished to implement the conditional visibility of the filter expressions on page 1, but this could be done with manual line breaks, prepared within NAV report code. Here is a screenshot of the new Wordlayout+ for report 108:
Within a Rich Text Control, you can use formatting expressions to display some parts of the content in bold or italic, for example. This is not possible within standard Wordlayout. Further information is provided in the following posts.
What are the drawbacks and how may they be improved?
The concept of Wordlayout+ differs in some respect from the standard NAV approach. Within the standard approach, the population of the content controls is done manually in the Word document part, using rather low level functions of the Open XML SDK library. Since this seems to be a difficult task, there are now severe limitations and missing functionalities, like for example nested repeaters or support of rich text controls. On the other hand, Wordlayout+ takes advantage of the built in functionality of the Word application to populate the content controls automatically, when opening or printing a document. The drawback is of course, that an instance of Word, preferably on the client side, has to be installed in order to use this built-in functionality. This has been strictly avoided with the standard approach. For example, no Word instance is necessary to use standard Wordlayout and print the result as a pdf. In order to accomplish this, a third party library, aspose.words, is used on the NAV server. If this server-side print-to-pdf functionality should be implemented in Wordlayout+, the content controls had to be populated, first. This would require a Word instance on the NAV server, which is not recommended. On the other hand, if Word is used on the client side, anyway, the pdf output could be directly created by Word automation methods like Microsoft.Office.Interop.Word. In this way, other tasks like removing empty content controls, could be handled, too. So the obvious extension of Wordlayout+ is to use client-side Word automation in order to process the document further or print it to some other format like pdf, e. g. – I will call the next step Wordlayout++…