I used https://docs.telerik.com/reporting/html5-report-viewer-howto-use-it-with-reportserver to setup an HTML5 Report Viewer with Report Server. After running the project, the viewer does not load. It seems that it could not find telerikReportViewer script.
Workaround: Instead of
<script src="/api/reports/resources/js/telerikReportViewer"></script>
use absolute path:<script src="http://yourreportserverhost:83/api/reports/resources/js/telerikReportViewer"></script>
Hi,
It's very frustrating having to type in Style Names in the Properties tool window.
All styles names both internal and external should be known by the standalone designer or Visual Studio designer.
This would be a big productivity boost.
Karl
Hi,
It gets frustrating always resizing every dialog so I can use it, each time I open them.
Please give the Report Designer Dialogs, and Visual Studio dialogs a save size setting so when reopened they will go back to the same size.
Thank you,
Karl
StyleRule Collection Editor Members list NEEDS to be resizable.
PLEASE SEE THE ATTACHED IMAGE
It's frustrating to have to scroll a Listbox horizontally to read the values.
This control should be wider by default, and then allow the user to resize, and then REMEMBER their resize.
Thank you,
Karl
i down last new version r3 2019 sp1 trial, create Simple example for binding table
eg:
reporting design tool render result:
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();
}
}
}
}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.
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:
<Grid>
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.
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.