When I need to populate a cell that I find using a DefinedName I should parse RefersTo to get Worksheet name. But DefinedName class contains Scope property which has CurrentWorksheet and Workbook properties (internal). It would be very useful if these properties could be public.
A reference that refers to the same cell or range on multiple sheets. Example: =SUM(Den1:Den31!C10) will sum C10 from all sheets between Den1 and Den3.
When a formula contains new lines, it is parsed incorrectly as follows: - When it is shared formula it breaks the imported expression and replaces it with #NAME? error. - In normal case it simply preserves the formula string converting it to StringExpression. Workaround: Remove the new lines in the formulas. Have in mind that this code will fix the issue only for the second scenario, when the formula is not shared. CellRange usedCellRange = workbook.ActiveWorksheet.UsedCellRange; for (int row = usedCellRange.FromIndex.RowIndex; row < usedCellRange.ToIndex.RowIndex; row++) { for (int column = usedCellRange.FromIndex.ColumnIndex; column < usedCellRange.ToIndex.ColumnIndex; column++) { CellSelection cell = workbook.ActiveWorksheet.Cells[row, column]; ICellValue value = cell.GetValue().Value; if (value.RawValue.Contains("\n")) { cell.SetValue(value.RawValue.Replace('\n', ' ')); } } }
When defaultThemeVersion is missing from the file, some styles are not shown when the document is opened in MS Excel.
WorksheetPageSetup.ScaleFactor is limited in the range 0.5 - 4 due to limitations in the UI implementations, but this is not needed in RadSpreadProcessing alone.
When printing or exporting to PDF, the left border of A1 cell is not printed/rendered.
When there is some long number value in merged cell and this cell is autofit, then in Excel the cell is visualized with "#####" because the column width is not enough. Workaround: As a workaround in some scenarios it is possible to call Merge method after AutoFitWidth method in order get the correct column width.
Define name which we can import looks like this: <definedName name="Test">Sheet1!$A$1</definedName> The case which can not be handled by RadSpreadProcessing looks like this: <definedName name="Test"><![CDATA[Sheet1!$A$1]]></definedName> The CDATA element is used to escape the inner text in order not to be parsed as XML. That means this is а valid case, and RadSpreadProcessing should handle it.
When there is a defined name referring many cells with long values, the Value of the defined name is string which does not contains the values of all the referred cells and ends with "...".
The item is closed as duplicated of https://feedback.telerik.com/Project/184/Feedback/Details/190065-spreadprocessing-implement-right-to-left-direction.
The way the RadSpreadProcessing decides if a row should be exported works slow. It iterates through all the rows in the UsedCellRange and checks if some property is set and if not, checks if some cell is set. This is slow because each row is checked one by one.
Xlsx documents with global print area defined cannot be imported. Message box "The name that you entered is not valid." is shown and internally SpreadsheetNameException is thrown. By default, print areas are defined in the xlsx files for specific spreadsheet: <definedName name="_xlnm.Print_Area" localSheetId="0">Sheet1!$A$1</definedName> but this one is without localSheetId property specified. MS Excel can import such document and even preserve the area, but do not respect it and doesn't have UI to clear it. By OOXML specification, this attribute is optional: <xsd:attribute name="localSheetId" type="xsd:unsignedInt" use="optional"/> Workaround 1 (includes processing the document with MS Excel): - Open the document in MS Excel - Choose Formulas -> Defined names -> Named Manager - Choose Filter -> Names with errors - Find all Print_Area defined names and delete them - Save the document Workaround 2: - Delete all print areas with OpenXML SDK Available in LIB version: 2017.1.213
The data validation is working. However, the text can't be localized by MS Excel with installed non-English language pack after import/export with SpreadProcessing. The problem is caused by an interpretation of the data validation rule as a text instead of as a formula.
The COUNT function counts the number of cells which contain numbers. Description from Microsoft here: https://support.office.com/en-US/article/COUNT-function-A59CD7FC-B623-4D93-87A4-D23BF411294C. Workaround: Implement such a custom function. See Custom Functions help article here: http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/custom-functions .
Add support for VALUE function. VALUE converts a text string that represents a number to a number. A list of the supported functions is available at http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/functions This function can be implemented as a custom function. Check the following resources for more details on how to achieve that: - http://docs.telerik.com/devtools/document-processing/libraries/radspreadprocessing/features/formulas/custom-functions - https://github.com/telerik/xaml-sdk/tree/master/Spreadsheet/WPF/CustomFunctions
There are scenarios when the default value of the columns is changed and may be different from 65. However, RadSpreadprocessing always exports the non-custom column values as 65. WORKAROUND: After importing the XLSX file you may make all columns to have custom values in order to preserve the column widths after the export. The following code snippet shows how this may be achieved for some Worksheet instance: CellRange usedRange = worksheet.UsedCellRange; for (int i = 0; i < usedRange.ColumnCount; i++) { ColumnSelection column = worksheet.Columns[i]; double width = column.GetWidth().Value.Value; column.SetWidth(new ColumnWidth(width, true)); }