When the culture of the thread is the default one, the private font (e.g. "Shadow Brush") will be replaced with a substitute in the Html5 Viewer (e.g. "Verdana") as the viewer does not respect private fonts. This is normal and expected behavior. When exported to PDF the text is displayed with the correct font ("Shadow Brush") but the embedded font as claimed by the Font properties of the PDF document reader is the substitute font ("Verdana").

When the culture of the thread is changed, the private fonts are not respected and not embedded in PDF rendered document at all. The text does not appear.

It would be nice, if not required by our client, to have 100% Web-based, Rich, Ad-hoc Reporting Solution.
Something similar to the one in ComponentOne Active Report 

Go to page https://demos.telerik.com/reporting/product-catalog?&skinName=default

Open Search dialog.

Type "Accessories" in search field. Wait for results.

Pick last result (Accessories - page 2) from results list. (page 2 will be opened - correct)

Close search dialog and open it again (or just clear search field).

Type "Accessories" in search field again. Wait for results.

Pick last result (Accessories - page 2) from results list again.

Incorrect behavior: page 1 will be opened instead of page 2; and first result item will be highlighted as selected instead of last result item.

Also I met situation when long results list was scrolled up to top but it was unclear how to reproduce it stable.

The following exception occurs when you attempt to add a Html5 Report Viewer from the VS item template in a project that already contains a CLR report:

"Error: Fail to add project reference System.Runtime.InteropServices.COMException (0x80004005): Adding 'WebApplication2' as a project-to-project reference would cause this project to reference itself. at VSLangProj.References.AddProject(Project pProject) at Telerik.Reporting.Vs.Common.ProjectManager.TryAddProjectReference(Project projectToReference)"

The viewer is still added successfully and displays the report.

Hi

If I run the angular report viewer within my main page, all is well. However if the report viewer is hosted in a <p-dialog> (or <p-overlaypanel>), the report does not render (even though data is loaded and the report can be exported). To confirm this, I even have the report visible in a <tr-viewer> on the main page behind the dialog and load them at the same time.

If the dialog is not visible when the main page opens, then the report viewer toolbar is in a column on the left, and is not operational. (see attached)

If the dialog is visible when the main page opens, then the toolbar appears at the top and functions normally. (see attached)

<tr-viewer #rptViewerBody
     [containerStyle]="viewerContainerStyle"
     [serviceUrl]="reportServerUrl"
     [viewMode]="'INTERACTIVE'"
     [scaleMode]="'SPECIFIC'"
     [scale]="1.0">
</tr-viewer>

vs

<p-dialog modal="true"
          appendTo="body" 
          header="Report"
          [(visible)]="showReport"
          [width]="1500" 
          [height]="1500">

        <tr-viewer #rptViewerDialog
            [containerStyle]="viewerContainerStyle"
            [serviceUrl]="reportServerUrl"
            [viewMode]="'INTERACTIVE'"
            [scaleMode]="'SPECIFIC'"
            [scale]="1.0">
        </tr-viewer>
</p-dialog>

In the code, I tried both of these container styles. The result for the dialog was that relative position rendered the toolbar (top or left), but absolute position rendered nothing at all (height became 0)

this.viewerContainerStyle = {
      position: 'absolute',
      top: '0px',
      left: '0px',
      right: '0px',
      bottom: '0px',
      ['font-family']: 'ms sans serif'
    };
this.viewerContainerStyle = {
      position: 'relative',
      width: '1300px',
      height: '1300px',
      ['font-family']: 'ms sans serif'
};

using @progress/telerik-angular-report-viewer": "7.19.718"

Thanks.

In HTML5 Report Viewer it is possible to intercept a client request (e.g. the request to export a report to a particular export format) and modify it like this:

{"format":"<script>alert(1)</script>","deviceInfo":{"enableAccessibility":false,"enableSearch":true,"BasePath":"/COAT_SIT/api/reports"},"useCache":true,"baseDocumentID":"31d0a1ca0162a3f13e92bf"}

The malicious script will be executed when the error message for a missing export format is displayed in the viewer.

When the user confirms changing the chart type through the "Change Chart Type" dialog window, the graph designer does not get refreshed and still shows the old chart type.

Underneath the graph item is actually changed and if the report is previewed, the new graph layout will be displayed. The current workaround is to refresh the graph designer by changing one of its properties that cause full item refresh - Culture, Graph title, NoDataMessage, etc.

Under Linux, when the font is set with Conditional Formatting some of the TextBoxes may be rendered with different that the expected Font in Docx. Other TextBoxes set with the same rule to the same font are rendered correctly.

The same report rendered in Docx under Windows produces the correct document.

As virtually every product with 10+ years of development, Telerik Reporting has a certain amount of legacy code that was considered immutable at the time of writing. During the refactoring of our codebase to make it compatible with .NET Standard, we introduced a few types from System.Windows.Forms namespace to substitute the ones missing in the current version of the framework. Such types are System.Windows.Forms.CheckState and System.Windows.Forms.ControlPaint. Some of these types are introduced in recent release of .NET Core 3 for Windows Forms and therefore a conflict occurs between the types in our assemblies and the ones declared in .NET Core. The error is thrown in compile-time and it is similar to the one shown below:

The type 'CheckState' exists in both 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'Telerik.Reporting, Version=13.2.19.918, Culture=neutral, PublicKeyToken=a9d7983dfcc261be'

In a future release of our product this collision will be avoided by using a dedicated enumeration for the duplicated types. A possible workaround would be to add an extern alias to the assembly reference of Telerik.Reporting. In this case all the references to Telerik.Reporting have to be edited to use the new alias, but the code that refers to the actual types from System.Windows.Forms will remain unchanged.

Here is how the Telerik.Reporting reference would look like in the application .csproj file:

  <ItemGroup>
    <Reference Include="Telerik.Reporting">
      <HintPath>..\..\..\Bin\netstandard2.0\Telerik.Reporting.dll</HintPath>
      <Aliases>telerikReporting</Aliases>
      </Reference>
  </ItemGroup>

Using the alias means that all the types in Telerik.Reporting namespace must be accessed with this alias. Unfortunately this also applies to C#/VB report definitions - their types must also be prepended with the alias, which could require significant effort. Here is a sample code file that initializes the WinForms Report Viewer and examines the CheckState of a CheckBox control in the form:

extern alias telerikReporting;

using System;
using System.Windows.Forms;

namespace WindowsFormsCoreDemo
{
    public partial class MainForm : Form
    {
        public MainForm()
        {
            InitializeComponent();
            this.Load += this.Form1_Load;
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            this.reportViewer.ReportSource = new telerikReporting::Telerik.Reporting.UriReportSource()
            {
                Uri = "SampleReport.trdp"
            };

            this.reportViewer.RefreshReport();
        }

        private void CheckBox_CheckedChanged(object sender, System.EventArgs e)
        {
            if (this.checkBox.CheckState == CheckState.Checked)
            {
                this.reportViewer.RefreshReport();
            }
        }
    }
}