Log in to start a topic

Exports and the View model

Posted by: mickiestimson on 8 September 2017, 3:51 am EST

  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    Hi,



    In our derived FPSpread class, we have a context menu which includes four items, one for each type of export: XLS, XML, HTML, and text.



    These four exports appear to behave substantially differently:



    XLS: (FpSpread.SaveExcel(…))

        * Does not honor the sort in the view model

        * Does not honor column moves when MoveContent == false

        * Always uses IFormatter of cell types to pass along cell formats to excel



    Text:  (SheetView.SaveTextFile(…))

        * Honors the sort in the view model

        * Honors column moves

        * Can use IFormatter of cell types or not depending on parameter passed to SaveTextFile



    HTML and XML: (SheetView.SaveHtml(…) and SheetView.SaveXml(…))

        * Does not honor the sort in the view model

        * Column moves (when MoveContent == false) cause it to match the incorrect header column with the data (PLEASE NOTE: DEFINITE BUG)

        * Order of exported rows is random, if a sort has been applied to the view model of the sheet being exported. (PLEASE NOTE: DEFINITE BUG - only took the time to verify on Html export though)

        * Does not use IFormatter - seems to just call ToString() on all Data Model cells.



    The fact that SaveExcel does not honor column or row sorts seems awkward but it’s not a big deal.



    The real problem is that SaveHtml and SaveXml are not at the level of polish or functionality of SaveTextFile.  Is this something still being worked on?  I know they are new to 3.0 so maybe they are as yet incomplete.  It would be nice if they could use the IFormatter of the cell types, and it would be nice if they honored the sorts in both the rows and columns. 



    Also, the HTML table seems to have font sizes that can change from row to row - it would be nice if all rows used the same font.  (Note: I think this may be related to the random order bug.)



    So, my question is whether any of these issues are going to be changed in the future.  As it is, I can’t see using SaveXml and SaveHtml.  They would be great though, if they could be improved to the SaveTextFile level of polish.



    Thanks very much for your help.

       







  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    I’ve also just noticed that the order of rows in an Html export seems completely arbitrary after an auto-sort has been done by clicking on a column sort indicator.  The order of the exported rows in that case is neither the order of the view model (as in Text export) nor the order of the data model (as in Excel export).  Seems randomly shuffled.  i’ve edited the original post to include this info.

  • seanl

    Posted 8 September 2017, 3:51 am EST

    I have reproduced this behavior and reported a bug to the developers (#21404).  It appears to be using the model indexes when it should be using the view indexes.  I will post an update when I have more information, such as a temorary workaround recommendation or a fix in a maintenance release.

  • seanl

    Posted 8 September 2017, 3:51 am EST

    I have a workaround from the developer that you can use until this bug is fixed.  The workaround is to create a temporary a FpSpread and a temporary SheetView with the same dimensions as the sheet you are exporting, then copy the sheet you are exporting into the temporary one using some of the clipboard support methods (not the clipboard itself though).  Here is the workaround code:



     

        Dim tempSpread As New FarPoint.Win.Spread.FpSpread

    
Dim tempSheet As New FarPoint.Win.Spread.SheetView

    
Dim cellInfo As FarPoint.Win.Spread.CellInfoRange

    
Dim rowInfo As FarPoint.Win.Spread.RowClipInfoRange = Nothing

    
Dim     columnInfo As FarPoint.Win.Spread.ColumnClipInfoRange = Nothing

    
Dim     cellRange As New FarPoint.Win.Spread.Model.CellRange(-1, -1, -1, -1)

    
cellInfo = FarPoint.Win.Spread.CellInfoRange.FromCellRange(FpSpread1_Sheet1, cellRange, rowInfo, columnInfo)

    
Dim dataObject As New DataObject()

    
dataObject.SetData(cellInfo)

    
dataObject.SetData(rowInfo)

    
dataObject.SetData(columnInfo)

    
tempSheet.RowCount = FpSpread1_Sheet1.RowCount

    
tempSheet.ColumnCount = FpSpread1_Sheet1.ColumnCount

    
tempSpread.Sheets.Add(tempSheet)

    
tempSheet.ClipboardPaste(FarPoint.Win.Spread.ClipboardPasteOptions.All, dataObject, cellRange)

    
tempSheet.SaveHtml(Application.StartupPath + “\21404_workaround.htm”)

    
tempSheet.Dispose()

    
tempSpread.Dispose()
     

  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    Thanks for your help, Sean.

    At first glance, it doesn't seem like that workaround accounts for the values of header cells, is that the correct impression?

    Will the Html or Xml exports use the IFormatter from the celltypes in the view model, like SaveText can do?  Is it a bug that they don't use IFormatter, or is that intended behavior?  SaveHtml writes out double precision numbers with 10 or 15 decimal places right now.

    Thanks again for your help.

  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    Don't worry about the workarounds, but i am still curious about this:

    Will the Html or Xml exports use the IFormatter from the celltypes in the view model, like SaveText can do?  Is it a bug that they don't use IFormatter, or is that intended behavior?  SaveHtml writes out double precision numbers with 10 or 15 decimal places right now.

  • seanl

    Posted 8 September 2017, 3:51 am EST

    It should be using the composed formatter from the style model for the sheet.  That is the Formatter property of the styleInfo returned by SheetView.Models.Style.GetCompositeInfo for the cell.  It should also be using the IParseFormatSupport interface to set the cached format string and IFormatProvider from the style model into the formatter if both the style model and the cell formatter implement the interface.  The exported results should be the same as what you see drawn on the screen or when the sheet is printed (as close as possible with HTML).

  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    Thank again Sean,



    That needs to be logged as a bug, then.  Doubles are being exported with 15 decimal places regardless of how they appear in the grid.  It’s the same behavior as SaveTextFile() when the UseIFormatter paramter is passed as false.

  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    please let me know the bug number for this so we can track it - we would love to use the html and xml exports but cannnot till these issues are resolved.  Thanks!

  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    regarding the xml and html exports not using the celltype’s IFormatter:



    please let me know the bug number for this so we can track it - we

    would love to use the html and xml exports but cannnot till these

    issues are resolved.  Thanks!

  • scotts-fp

    Posted 8 September 2017, 3:51 am EST

    Hello,

    The bug number for this is 21404.

  • mickiestimson

    Posted 8 September 2017, 3:51 am EST

    Thanks Scott,



    That defect was the one for the row indexing problem - is it also for the output formatting?  These are two different issues.

  • scotts-fp

    Posted 8 September 2017, 3:51 am EST

    Hello,

    Both bugs were assigned to the same bug number. These issues will be fixed in the next maintenance release.

  • ahmdftdar60

    Posted 6 May 2019, 7:06 am EST

  • ahmdftdar60

    Posted 6 May 2019, 7:06 am EST

  • ahmdftdar60

    Posted 6 May 2019, 7:07 am EST

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels

  • © 2023 MESCIUS inc. All Rights Reserved.  ·  1.800.858.2739

    All product and company names herein may be trademarks of their respective owners.