Currently a single instance of the WPF Report Viewer will often use multiple different HttpClient instances to talk to the Report Server.  This means that cookies added as part of earlier requests may not be sent in later requests.  If the Report Server is behind a load balancer that uses cookies to implement 'sticky sessions', this loose behavior with cookies will cause requests to get routed to different servers which is not ideal.  It is possible to use a storage mechanism on the server that natively supports a web farm (such as the Redis storage option) but that can be tricky to set up.  

Instead, if the report viewer were to re-use the same HttpClient instance for all requests (including initial render request, export requests, print requests, etc.), the load balancer could work to route all requests to the same web server and then any storage mechanism (such as the simple File storage option) would work.

This issue was reported back in 2017 and I'm running into the problem again in 2022.  See: https://www.telerik.com/forums/wpf-reportviewer-cookie-behavior

in the new/current Version "16.2.22.914", when dragging an DataSource-Field on the Report, the resolved expression is wrong.

In the previous Version "16.2.22.622", this worked as expected, see Screenshot.

The attached report demonstrates the issue.

Enable retaining editable textboxes when Exporting to PDF.

For example a PDF Re-order form with editable textboxes for order Quantity so the user can enter order Quantities.

I have a multipage report and my Html5 Viewer is set up in an ASP.NET Core application in .NET 5. The viewer's settings are:

viewMode: "PRINT_PREVIEW",
scaleMode: "FIT_PAGE_WIDTH",
pageMode: "CONTINUOUS_SCROLL",

The problem is that I cannot scroll down to the end of the report.

The issue may not occur in other frameworks with the same report.

The issue may be observed with the online demos - see the linked screenshot.

If I go back and add new records, the total rows count gets updated but still doesn't count the initial rows.

When a TRDP/TRDX report is imported to a CS report, the produced .designer.cs does not have Unicode encoding, instead, it is with ANSI encoding.

Because of this, some of the report text might instead be displayed as ????

The workaround is to Save As the file, from Visual Studio, with Encoding which will open a window where you may change the encoding to Unicode.

As explained in this support ticket (https://www.telerik.com/forums/specify-default-print-settings---number-of-copies), our customers want to be able to set the default value of the number of copies for a report since they require multiple copies for their business processes.

Would it be possible to enable setting the default values for the printing when a report is generated?

The following Base64 image:

iVBORw0KGgoAAAANSUhEUgAAATIAAABaCAYAAAA7FtpGAAAABHNCSVQICAgIfAhkiAAAAZ1JREFUeJzt1EkOgkAAAEHw/3/Gk9HoIEsksZOqm8wCDtrzNE3L9GJZnh/nef649j62Zu+a0bzR/Me80bWttXuf6ej3PHNWZ85y7V6j8T17nd3v6LtaG79q3mj+0fdy9Pz2/g/OzLvqHLf2+MUZfPutbN1j6/2N1t6+PyrA/xMyIE/IgDwhA/KEDMgTMiBPyIA8IQPyhAzIEzIgT8iAPCED8oQMyBMyIE/IgDwhA/KEDMgTMiBPyIA8IQPyhAzIEzIgT8iAPCED8oQMyBMyIE/IgDwhA/KEDMgTMiBPyIA8IQPyhAzIEzIgT8iAPCED8oQMyBMyIE/IgDwhA/KEDMgTMiBPyIA8IQPyhAzIEzIgT8iAPCED8oQMyBMyIE/IgDwhA/KEDMgTMiBPyIA8IQPyhAzIEzIgT8iAPCED8oQMyBMyIE/IgDwhA/KEDMgTMiBPyIA8IQPyhAzIEzIgT8iAPCED8oQMyBMyIE/IgDwhA/KEDMgTMiBPyIA8IQPyhAzIEzIgT8iAPCED8oQMyBMyIE/IgDwhA/KEDMi7AzLSZLNf8xCVAAAAAElFTkSuQmCC

is recognized by the Reporting engine as SVG, which results in the following error in the PictureBox:

An exception has occurred while processing 'pictureBox1' item:
System.Xml.XmlException: The '�' character, hexadecimal value 0xFFFD, cannot be included in a name. Line 1, position 5.
   at System.Xml.XmlTextReaderImpl.Throw(Exception e)
   at System.Xml.XmlTextReaderImpl.ParseElement()
   at System.Xml.XmlTextReaderImpl.ParseDocumentContent()
   at System.Xml.XmlLoader.Load(XmlDocument doc, XmlReader reader, Boolean preserveWhitespace)
   at System.Xml.XmlDocument.Load(XmlReader reader)
   at System.Xml.XmlDocument.LoadXml(String xml)
   at Telerik.Reporting.Svg.RadSvgImage.SvgDocumentFromXml(String xml)
   at Telerik.Reporting.Processing.Imaging.SvgImageItem.CreateImageInfo()
   at Telerik.Reporting.Processing.Imaging.IImageInfoMapExtensions.StoreImageData(IImageInfoMap imageInfoMap, IImageItem imageItem, ICache cache)
   at Telerik.Reporting.Processing.PictureBox.ResolveImage(Object value)
   at Telerik.Reporting.Processing.PictureBox.ProcessItem()
   at Telerik.Reporting.Processing.ReportItemBase.ProcessElement()
   at Telerik.Reporting.Processing.ProcessingElement.Process(IDataMember dataContext)

Hello

I have a problem with report generating. We use HTML5 report viewer and basic implementation of ReportsControllerBase on server.
I've noticed that we have the CPU/memory recourse consumption after immediately pressing Stop Rendering button. The time of consumption recourses is the same as time without cancelling(about 18-20 second in my example)
There is log with calls of report generating. Last one with cancelling, previous without. 
(see
*** ReportProcessor.ProcessReport DONE in 00:00:16.1918150 ***
and
*** ReportProcessor.ProcessReport DONE in 00:00:16.8522950 ***)

I've investigated how cancelation is working.
The Stop Rendering button send DELETE request to ReportsControllerBase.DeleteReport endpoint. It does something and set IsDeleted flag for document.
Then DocumentCancellationController.ThrowIfCancellationRequested() is called in some specific places in app. You can see that method in log.txt, so it was called after pushing the button.

I've profiled the hot path of generation of report. See hotpath.png.
The most CPU intensive work happens in ReportProcessor.ProcessRepourtSource()...
Pay attention to rendering calls.png - the first red dot here - ReportProcessor.ProcessRepourtSource() call.
The second - where the exception and actual cancelation happens.
I'm expecting it should happen much earlier and cancellation of generation of document(and resources consumption) will finish ASAP.

By the way, I see some cancelation checks in ReportProcessor.ProcessRepourtSource() as well - see throwIfCancellation.png
But cancelation request came after these check and most intensive CPU works already started.


Is it possible to fix that?

Due to breaking changes related to the Kendo state classes - https://docs.telerik.com/aspnet-core/styles-and-layout/components-rendering-overview#state-classes, report parameters loaded in the HTML5 Report Viewers that use the ListView widget, are not selected properly, thus the report is not updated with a new report source and the data does not change.

Ideally, if the user prints a report, the output should be the same as what they see on the screen.

Currently, if the user prints/exports the report sometime after previewing it, the data will be updated and they will not get what they see.

Currently, the WinUI ReportViewer has a hard dependency on Windows due to the fact that the internals rely on the Win32 print dialog.

This means I cannot define the ReportViewer in a WinUI class library to be shared with multiple front-end WinUI projects. If you attempt to do this, there's an internal crash because the project cannot resolve  System.Windows.Forms.

This feature request is ask if you can replace the Win32 print dialog with the WinRT printing API. 

Research Note:  Here's a GitHub thread where Microsoft is discussing the topic Question: Printing in WinUI 3 Desktop · Issue #4419 · microsoft/microsoft-ui-xaml (github.com). Here's their current recommendation:

var hWnd = WinRT.Interop.WindowNative.GetWindowHandle(App.StartupWindow);
var printMan = PrintManagerInterop.GetForWindow(hWnd);

await PrintManagerInterop.ShowPrintUIForWindowAsync(hWnd)

If I put the following content in an HtmlTextBox, when I open the preview mode of the designer or look at it in the Html5 Report Viewer I get annoying extra gaps:

<p>Comment</p><p>Comment</p><ol><li>List</li><li>List</li><li>List</li></ol><p><br></p><p>Comment</p><p>Comment</p>

I tried to replace these <p>-tags with <div>-tags:

<div>Comment</div><div>Comment</div><ol><li>List</li><li>List</li><li>List</li></ol><div><br></div><div>Comment</div><div>Comment</div>

It helps. But there are some other tags that cannot be replaced (tags of ordered and unordered lists for example). And these gaps are still rendered. 

When exporting the tags for the document's Table of Contents Telerik Report Designer exports TOC leaders as distinct tags, requiring that they be removed when completing the accessibility tagging for the document. Leaders - the ellipses found in the Table of Contents (e.g., Introduction ...................... Page 3) between the TOC item and the page number will be read by assistive technology as "dot dot dot dot dot..." etc. They need to be deleted from the tag tree. Please Artifact them or (preferably) NOT tag them on the export. Thanks.

Reference: 

https://www.levelaccess.com/pdf-table-of-contents/

https://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/pdf.html 

When exporting to PDF from Telerik Report Designer the software creates a list of flat links for each TOC entry, but the links are separated in the structure from the TOC Label. While a good start, it would be better to use a main TOC tag under which each line in the TOC would receive a TOCI (Table of Contents Item) tag. Each TOCI would contain the label and link for the respective item. Attaching a few examples to assist.

References:

https://www.hhs.gov/sites/default/files/pdf-tagging.pdf (page 29).

https://www.pdflib.com/pdf-knowledge-base/pdfua/the-pdfua-standard/ 

Using the Default or Material Kendo Theme (v5.6.0) with the Telerik HTML5 Report Viewer, the Boolean parameter which uses a Checkbox for it's display, is not visible (this may affect other themes as well).

I confirmed an older version v4.40.0 has a height and width set for the k-checkbox CSS class as such:

https://unpkg.com/@progress/kendo-theme-material@4.40.0/dist/all.css

.k-checkbox {
    border-radius: 2px;
    margin: 0;
    padding: 0;
    width: 16px;
    height: 16px;
    line-height: initial;
    border-width: 2px;
    border-style: solid;
    outline: 0;
    box-sizing: border-box;
    background-position: center;
    background-repeat: no-repeat;
    background-size: contain;
    display: inline-block;
    vertical-align: middle;
    position: relative;
    cursor: pointer;
    -webkit-appearance: none;
}

while the latest v5.6.0 does not:

https://unpkg.com/@progress/kendo-theme-material@5.6.0/dist/all.css

.k-checkbox {
    margin: 0;
    padding: 0;
    line-height: initial;
    border-width: 2px;
    border-style: solid;
    outline: 0;
    background-position: center;
    background-repeat: no-repeat;
    background-size: contain;
    display: inline-block;
    flex: none;
    vertical-align: middle;
    position: relative;
    cursor: pointer;
    -webkit-appearance: none;
}

The checkbox is actually on the page, but is so small it's basically invisible and completely unusable, requiring a manual CSS override to fix.