After dragging a report viewer control from the Visual Studio toolbox to the surface of a Windows Form, the viewer is added to the component tray but it is not added to the Controls collection of the form. Thus, the viewer is not displayed when running the application.
Also, some properties of the report viewer, such as the ReportSource property, are not serialized properly after being modified through the Visual Studio properties window.
Currently, one can work around these issues by manually editing the InitializeComponent component method of the form's .Designer.cs file.
I had an issue with watermarks being present in the generated PDF despite the license validation passing. In the trace log, I was seeing this:
x.x.x.x.exe Information: 0 : *** ReportProcessor.ProcessReport STARTED *** x.x.x.x.exe Information: 0 : SQLite x64: v3.50.4 x.x.x.x.exe Information: 0 : x.x.x.x.exe Information: 0 : *** ProcessReport #0 "Invoice" STARTED *** x.x.x.x.exe Information: 0 : *** ProcessReport #0 "Invoice" DONE in 00:00:00.6363067 *** x.x.x.x.exe Information: 0 : x.x.x.x.exe Information: 0 : *** ReportProcessor.ProcessReport DONE in 00:00:00.7891276 *** x.x.x.x.exe Information: 0 : x.x.x.x.exe Information: 0 : License check for assembly Telerik.Reporting, Version=19.3.25.1119, Culture=neutral, PublicKeyToken=a9d7983dfcc261be: True x.x.x.x.exe Information: 0 : x.x.x.x.exe Information: 0 : *** Render Report #0 "Invoice" STARTED *** x.x.x.x.exe Information: 0 : ReportName: Invoice; DocumentName: Invoice; Extension: PDF x.x.x.x.exe Information: 0 : DeviceInfo Contents x.x.x.x.exe Information: 0 : =================== x.x.x.x.exe Information: 0 : ChangingPermissionType: "" x.x.x.x.exe Information: 0 : ComplianceLevel: "None" x.x.x.x.exe Information: 0 : CopyingPermissionType: "" x.x.x.x.exe Information: 0 : DocumentAuthor: "" x.x.x.x.exe Information: 0 : DocumentCreator: "" x.x.x.x.exe Information: 0 : DocumentKeywords: "" x.x.x.x.exe Information: 0 : DocumentNaturalLanguage: "" x.x.x.x.exe Information: 0 : DocumentProducer: "" x.x.x.x.exe Information: 0 : DocumentSubject: "" x.x.x.x.exe Information: 0 : DocumentTitle: "" x.x.x.x.exe Information: 0 : EnableAccessibility: "False" x.x.x.x.exe Information: 0 : EndPage: "0" x.x.x.x.exe Information: 0 : FontEmbedding: "None" x.x.x.x.exe Information: 0 : ForceLicenseWatermark: "True"
The issue turned out to be due to caching, but the output puzzled me while I was debugging this. Turned out `ForceLicenseWatermark` is always true (the misleading part), but only has an effect when the license validation fails.
When using screen reader applications like JAWS or Narrator, those tools read accessible reporting PDFs in an incorrect order. For example, if I have two items in the report, the reader will read the second item first.
Additionally, images whose AccessibleDescription I have set may be read multiple times..
I have noticed that the performance of exporting reports has gotten worse in recent releases. After investigating, I found out that this is likely caused by the sheer size of the code in my projects.
To prove this, I created a simple application that renders a report to PDF programmatically. Then, I created 10 000+ dummy classes in the same project, and tried rendering the report again. The performance was noticeably impacted by this change.
If cells grow or shrink, if there are hidden cells, any time a report section grows vertically, the next section/table is not respecting the growing of the previous item and text prints in the wrong spot or the table overlaps the previous table.
A potential workaround is to manually convert the troublesome tables to lists where possible.
I have a solution with two projects: one containing a report, and another for the objects.
The first one has a project reference to the second, and the objects are used within an ObjectDataSource component in the report from the first.
I open the solution, build the project with the objects, but the Data Explorer of the ObjectDataSource component in the first project with the report does not get automatically updated. I have to reconfigure the ObjectDataSource manually for the change to take effect.
I load multiple variants of the Segoe UI font as private fonts in my application:
<!-- Segoe UI -->
<add fontFamily="Segoe UI" path="Fonts\SegoeUI\segoeui.ttf" fontStyle="Regular" />
<add fontFamily="Segoe UI" path="Fonts\SegoeUI\seguisb.ttf" fontStyle="Semibold" />This leads to issues, as there is no "Semibold" option in the System.Drawing.FontStyle enum.
The workaround that can be used to avoid this problem is to use unique font family names. For example
<add fontFamily="Segoe UI" path="Fonts\SegoeUI\segoeui.ttf" />
<add fontFamily="Segoe UI Semibold" path="Fonts\SegoeUI\seguisb.ttf" />
When adding an embedded image to a coded report in the Standalone Designer .NET, the original RESX file is not modified.
Only the original DESIGNER.CS file is modified. This leads to the new PictureBox being present but empty after deleting the dedicated folder named after the report (beside the designer EXE).
When my application is hosted on Windows, Arabic date values appear reversed in the day part during PDF export with the Skia graphics engine. For example, 2025/01/01 is displayed as /01/10 when Arabic digits are used.
With the GDI graphics engine, the Date values are rendered as expected.
I use the kendovalidator before rendering the report to check the correct parameter of initial and final date.
However, the validation fails because additional inputs (for the "Send Email" functionality) are included in the HTML output of the viewer even though I have disabled it.
I believe that if the "Send Email" option is disabled the mail data panel should not be created.
All of my report parameters have their AutoRefresh setting set to False, and the parameters do not depend on each other, they are not cascading parameters. The parameters have available values.
If I change the value of one of the parameters, despite the above settings, all of the other parameters' data is re-retrieved(even if those parameters are not visible).
This causes issues because the "Preview" button is disabled until the parameters are refreshed, and makes the UX bad since if the connection is slow, the end-users will have to wait for the parameters area to refresh after changing any parameter value.
When a system tells users they should look into the report parameters as the reason the report isn't displaying. It's reasonable for your users to believe you aren't misleading them.
The report viewer error message misleads users. In reality the parameters are correctly configured and it the repot URL could be wrong. Or a variety of other issues are at play; for instance, a problem with you connection string will also return the "Unable to get report parameters" error message. I'd like to see this error message at minimum changed to "report can't display." It's better to throw out a generic message vs having users spend hours or days troubleshooting the report parameters. Better yet a proper catch/validation system put into place please.
I have a simple report with two TextBoxes in the detail section. In one of them, the content wraps as it doesn't fit, and in the other, it doesn't.
When I export to Excel (XLSX), under each detail section, there is an empty row.
When I left only the TextBox with the wrapping content, there were no empty rows in the Excel file.