When one item is selected, or multiple items are selected where they all have the same size, the Width and Height property is accessible and will be applied for all selected elements. If multiple elements are selected and they do not all have the same width and height, the property becomes blank, and you do no longer have access to the Width and Height property.
It would be great to still have access to the properties so a value can be applied for all selected elements.
When a section is disabled by setting the Visible property to false, the section remains visible in the designer without any visual indication that it is invisible when rendered. Adding such a visual indication would allow users to more easily see that it is disabled.
Having a cross over the section, making it disappear from the designer window, or showing somehow it is disabled would make it easier to understand, as currently the only way to check this is by reading the value of the Visible property in the Properties pane
kendo.all.js:105032 Uncaught TypeError: Cannot read property 'find' of null
at init.toggle (kendo.all.js:105032)
at P (telerikReportViewer:9)
at Object.<anonymous> (telerikReportViewer:9)
at Object.trigger (telerikReportViewer:9)
at Object.trigger (telerikReportViewer:9)
at se (telerikReportViewer:9)
at Object.setDocumentMapVisible (telerikReportViewer:9)
at b (telerikReportViewer:9)
at E (telerikReportViewer:9)
at o (telerikReportViewer:9)Then the HTML5 ReportViewer is set to pageMode SINGLE_PAGE and an update triggeres the Viewer to retrieve the document, the new document is never displayed.
Status messages appear as usual, "Loading report", "0 pages loaded so far" and "Done. Total 1 pages loaded." but the gray overlay of the Viewer is never removed and the report is not updated. Parameters and toolbar-menu can still be interacted with and trigger new updates, but will not cause the viewer to show the report correctly. Refresh required
ReportViewer will resize correctly when the window is resized by manually dragging the frame, but when 'Maximize' or 'Restore Down' buttons are used, the resize will not occur.
If continues scrolling is turned on, the next page to load in will be in a different size because it will be in the correct size, while the first page remains in the previous size.
A work-around is to add this codesnippet to the HTML, which will trigger the resize:
function resizeViewer() { $("#reportViewer1").trigger('resize'); }
window.addEventListener("resize", resizeViewer);
Implementing Drag&Drop for the Web Report Design is a major step toward feature parity with the Standalone Designer, and helps end-users leverage their established workflow when migrating to the Web Report Designer.
The parametersAreaVisible property of the angular report viewer allows controlling the visibility of the report parameters area.
Currently, this property can only be set. Reading the property doesn't reflect the current visibility of the report parameters area.
While jquery can be used as a work around to determine the visibility of the report parameters area (by reading the width of the corresponding DOM element), a proper angular API would be nice.
On numerous occasions I've found that the need to float or rearrange the designer windows such as the data explorer, properties or group explorer window would be very beneficial to my workflow.
As well this request should consider the ability of the data explorer and report explorer to be decoupled so as both can be visible simultaneously.
Normally table's of context are formatted with roman numerals. Based on the responses in the forum, only Arabic numbers are allowed. Request the ability to change the formatting of the rule numbers and restart the page numbering after the TOC.
When a report is rendered by the REST Service, and that report has an element with applied 'Navigate To Report'-action, the full path of that file is being used as a reference, instead of a relative path or just the report-name.
A possible solution would be to expose a ParametersAreaLoaded and ParametersAreaUpdated events with the needed arguments.
This will make migration from Silverlight easier. There the user has a direct access to them through the ReportViewerModel.