When merging the ReportViewer's WPF theme dictionaries from the DLL in App.xaml, the VS2019 Designer fails due to a problem with a ZoomComboBoxStyle definition.

This causes all Telerik UI for WPF control's styles fail to load in the Visual Studio designer.

WORKAROUND

Instead of App.xaml, merge the ReportViewer's theme dictionary closer to the control.

For example in the ReportViewer's direct parent:

When you try to send the report through the SendMailMessage functionality but an exception is thrown, the report will disappear. If you click on Refresh and try again with fake data, the exception will be thrown but the report will remain. If you prefer to refresh it automatically, you can use the error event:

var viewer = $("#reportViewer1")
.telerik_ReportViewer({
    serviceUrl: "api/reports/",
    reportSource: {
        report: "Report Catalog.trdp",
    },
    error: function (e, args) {
        console.log("This event handler will be called after a page of the report is ready.");
        console.log("The error message is: " + args);
        viewer.refreshReport();
    },
    viewMode: telerikReportViewer.ViewModes.INTERACTIVE,
    scaleMode: telerikReportViewer.ScaleModes.SPECIFIC,
    scale: 1.0,
    enableAccessibility: false,
    sendEmail: { enabled: true }
}).data("telerik_ReportViewer");

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.

Hello, 

It would be nice to control the report loading animation during a report viewer refresh. We are refreshing a report every x seconds and it appears to be flickering during a refresh.

Thank you.

If a table-based item (Table, List, Crosstab) does not fit in a single page and needs to occupy more than one page, its bottom border is not drawn on the first page and its top border is not drawn on the second (subsequent) page. This behavior is by design and its purpose is to help the users visually distinguish the table as a single item. The table has only one top and bottom border and they are displayed at the beginning and at the end of the table, regardless how many pages the table actually occupies.

Since users might find this confusing, a table should have a property controlling this behavior. The default state of the property will preserve the current rendering. If the user explicitly sets the property, then the table will draw its top and bottom borders on every page it occupies.

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();
            }
        }
    }
}

As in Ticket with ID 1440072 requested we are looking for a funktionallity to send Reports via E-Mails with the WPF ReportViewer. As only the HTML-5 ReportViewer currently supports the E-Mail sending we would request the feature for WPF as well.

Best Regards,

Martin