OnGetDocument and OnCreateDocument can be overridden in the ASP.NET Web API ReportsController to modify the report documents as explained in the KB Modify exported report document prior to serving it to the viewer client.

In ASP.NET Core this is not possible as OnGetDocument and OnCreateDocument don't exist.

As I outlined in my Issue with the Cross-section Item post to the forums, the current implementation of the cross-section item carries the following limitation:

The Cross-section item uses the report's data context and cannot be evaluated against detail or group data. The processing engine produces a single instance per each Cross-section item in the report definition, therefore its style or visibility cannot be changed based on data fields.

For invoice (or sales order) style reports this places a severe limitation on the complexity of the report.

One of my current projects requires me to create a report layout that can be run for multiple invoices from multiple customers, where each customer has their own unique set of flags that control what information is included on their invoices for each line item of the invoice.

My current version of this report works great when it is run for a single invoice or invoices from a single customer (or from customers who use the exact same set of print flags) by binding the visibility and begin/end margin values of the lines that start in the groupHeader section, cross through the detailSection, before finally terminating in the groupFooter section.

This can be seen clearly in the 2 attached invoices, one with lots of columns of information (called: Invoice with lots of detail columns.png), and another where the customer has been configured with all the additional information toggled off (called: Invoice with minimal detail columns.png).

Unfortunately, because of the cross-section item's current limitation, when I run the report for both invoices the lines attributes/visibility are set based on the customer flags of the "first" invoice in the group, and do not get reset for subsequent invoices.  This can be seen in the attached file: Behavior when including both invoices.png.

I understand that if a cross-section item begins/ends in a page/report header/footer, then having it's attributes change based on group-specific data would be less than ideal.  But when the line beginning and end points are restricted to a group header and footer, as it always would be for a report layout used for multiple invoices or sales orders, then having that line's attributes change based on the data is the only way to use this functionality for these types of complex reports.

NOTE: While there is a workaround using the attributes/visibility of detail columns, vertical lines in the detail section, and their associated headers and totals textboxes in the groupHeader and groupFooter, it results in an unprofessionial looking report because of the difficulty in getting the variable border and detail vertical lines to line up precisely (and it is very time-consuming to try to implement).

SUMMARY:

Changing the Cross-section item implementation to allow it's data context to be evaluated against detail or group data when the line's terminators are restricted to groupHeader/Footers would allow for its use in more complicated report layouts.

BTW: interally, we refer to these reports as Mighty Morphing Invoice Reports™!!!

If you drag and drop a List in a Report in the Web Report Designer, and then reduce its height and the height of its inner Panel from the Property editor, initially, the changes are respected. When you save the changes and reopen the same report, the Panel recovers its previous Height.

The issue is not reproducible when modifying List or Panel size with mouse dragging.

There seems to be an issue with the filter / parameters with comma separated values for Multivalue.  I've tried numerous ways to get this to work directly in the preview function on the report designer.  Nothing done so far works.

Set Filter to multi
Set Parameter to IN 

Typed in value, value - typed in 'value','value', etc.  This is a basic text field so I am not certain as to what exactly should be put in the filter box to allow for 2 or more values in a filter.

This produces data on the report with IN and Multivalue 

This produces an error

The current data set presented in the report did not produce any significant content, so no pages were generated. If you need to see the whole report content, including blank pages, please contact the report author.

Please advise exactly how to do this with an example.  I have scoured the forums and the documentation with no relevant information that works for a multiple value field.

Thanks in advance.

Allison

Hi,

I request you to add a new property in the report object when we unpackage the TRDP file to get a list of fields that are used in the report template.

Currently, We are not able to identify how much data we need to extract from the database as we are using the ObjectDataSource component in the report we have the number of fields in the data source but fewer were used in the report template hence on the performance point of view we need to get data only for those fields.

Thanks.

The TOC may be rendered with incorrect font size and incomplete LeaderSymbols when rendered with libgdiplus under Docker with Linux. See the linked screenshot.

It would be helpful to enable printing a table header when no data is available and the NoDataMessage is set. We frequently have tables with one or more static headers that may not have any data - depending on the supplied report parameters. We set the NoDataMessage to display an appropriate message, however, we would like to continue displaying the table title and column headers.

We currently accomplish this with a Panel + Table but that is inelegant. It is more designer friendly to design the table once and reposition and resize it as necessary.

Here is an example screenshot of the issue we have now

If you add the following HTML text that contains two identical paragraphs in an HtmlTextBox, the first paragraph will contain the bold/strong text and the second will not. The specified font family doesn't have a font face for the bold text installed:

<p><span style="font-size: 9pt; font-family: arialmt"><strong>BILLING</strong>&nbsp; The total cost of the hearing aid(s), </span></p>
<p><span style="font-size: 9pt; font-family: arialmt"><strong>BILLING</strong>&nbsp; The total cost of the hearing aid(s), </span></p>

If you use two HtmlTextBoxes to display the two paragraphs, the second HtmlTextBox won't contain the bold text.

When you use a font family, which bold font face is installed, the HTML is rendered consistently.

I have a report with a Graph with BarSeries and DateTime X-axis and Numerical Y-axis. The Series has ToolTip that is displayed correctly in the Standalone Report Designer. However, the Html5 Report Viewer does not display the tooltips. The HTML element for the bars does not contain the needed attributes:

data-tooltip-title="Value" data-tooltip-text="10" data-role="tooltip"

and looks like this:

<path d="M588.32 51.51 L589.05 51.51 L589.05 242.89 L588.32 242.89 Z" fill="none" stroke="lime" stroke-width="2" stroke-dasharray="none" stroke-linejoin="bevel" stroke-linecap="butt"></path>

Please see ticket #1553960 for examples and the initial ticket.

Request: Update isValidXhtml to take in an optional argument that controls whether or not the validation ignores unsupported HTML tags. With the understanding that unsupported tag types do not get output in the HtmlTextBox.

Because the function isValidXhtml evaluates to False for unsupported tag types while the HtmlTextBox just ignores unsupported tag types, there is a disconnect between what the HtmlTextBox can display vs what isValidXhtml allows to be displayed.

This change would allow more flexibility when trying to validate HTML and display it in the HtmlTextBox.

Use case: I have been working a lot with emails and trying to display them within a report. When I use isValidXhtml to validate the email before outputting in an HtmlTextBox, most emails evaluate to False and do not get displayed since they contain many unsupported tag types. However when I remove the validation, more emails get displayed because the HtmlTextBox ignores unsupported tag types. This update would allow more HTML to be considered "valid" by the isValidXhtml function, with the understanding that unsupported tag types will not get displayed.