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.

If we initialise the control in "FIT_PAGE_WIDTH" mode it essentially renders as expected but zooming in can actually then cause it to zoom *out*.

Reproducible in the `CSharp.NetFramework.Html5IntegrationDemo` example project as well, once you set the `scaleMode` property to "In FIT_PAGE_WIDTH".

In print preview, if you have "FIT_PAGE_WIDTH" as a default scale mode, once you click the "toggle full page/full page width" button, it's never possible to get it to return the original fit-page-width size (it seems to cycle between 3 different zoom modes, but none of them fill the entire control width).

It looks like the report viewer correctly sets the scale mode during initialization. However, when toggling the mode later, it sets it incorrectly.

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.

I have a report where I have placed a bunch of textbox items at the bottom of the page header that I use as headers for my data that I display in the detail section.

When I run the report in a Docker Linux container, where the Skia graphics engine is used, the items at the bottom edge disappear when rendering the report in the web report viewer(HTML5 Interactive) rendering.

The issue does not occur when I render the report with the "PRINT_PREVIEW" viewMode setting or when I use GDI+..

As of now the Reporting team provides only part of the source code - mostly the code that targets .NET Framework 4.6.2.

Please expose more of the code to your customers, like Telerik Reporting engine for .NET 6+ and corresponding REST WebAPI.

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.

Hello Team Support,

I work with the ReportViewer in WPF. I modified the description of some format in my App.config.

When I export my report, if the description is too long, it does not fit the message window anymore.

Here is a screenshot of my issue:

Thank you in advance.

Best regards,

Jonas

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.

Currently, page breaks in reports are static and cannot adapt to dynamic conditions during rendering. This limitation makes it challenging to format highly variable reports where layout requirements depend on runtime data or page positioning.

The requested feature would allow developers to define expressions or rules that determine whether a page break should occur, considering factors such as:

• The current page number
• The position of a specific control on the page
• Other Internal report variables

Benefits

• Enables precise control over report layout for complex, data-driven scenarios
• Improves usability for industries requiring strict formatting standards (e.g., financial, healthcare, compliance reporting)
• Aligns functionality with competitive reporting tools like Crystal Reports, enhancing product competitiveness
• Reduces manual workarounds and simplifies report design for advanced pagination needs

Similar, but more specific request already exists:
https://feedback.telerik.com/reporting/1356665-add-conditional-page-breaks-based-on-report-group-page-number-duplex-printing

See also my ticket: 1701322

I have successfully installed the ODBC and OLEDB providers for Visual FoxPro 9 and they appear in the Windows 32-bit ODBC Data Sources under System DSN.

The drivers are discovered when I use Standalone Report Designer x86 from 17.2.23.1114 and older ones built against .NET Framework 4.0.

The same drivers are not found on the same machine when I use Standalone Report Designer x86 from 18.3.24.1218 built against .NET Framework 4.6.2.

My use case is a multi-select parameter that is based on a dataset; and the dataset is filtered by 2 other parameters.

The dependent parameter editor is shown as a SpinButton rather than a multi-select editor in the Blazor Native Report Viewer:

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"  />