Culture settings is not correctly applied for SheetView loaded from deserialized sheetview collection object

Posted by: spm0 on 8 September 2017, 1:16 pm EST

  • Posted 8 September 2017, 1:16 pm EST

    Hi All,    


     In the attached VS.Net project, CodeDemo.xls file (stored in \bin\debug directory) is formatted using number formatting - the type of formatting applied is explained in excel file.  The application can load this excel file to spread control in different culture formats by using culture combo box and “Load” button.  It can be seen that the spread control correctly displays the data based on the culture chosen in the combo box i.e., if “US culture” is selected then dot (“.”) is used as a decimal separator and if “Swedish culture” is used then it displays the decimal separator as comma (“,”). 


                Now, the above works perfectly, however if we serialize the object (by clicking on “Serialize” button) and change the culture (lets say from “US” to “Swedish)  and reload the serialized SheetView object (by clicking on “Deserialize” button) the data that is displayed seem to be having inconsistent format.  It can be seen that  in the SheetView B1 and B2 cells are correctly displaying the data based on the current culture, however B3 cell seems to have wrong decimal separator.  Why is this inconsistency? Could this be a bug?  Please suggest.


     


    Note: 1) Change the attachment name from "FarPoint-NumberFormat.jpg" to "FarPoint-NumberFormat.zip".


    2) The B3 cell in the excel file is exclusively formatted to have 3 decimal places, and it seems to be contributing to the problem.  Also, the B3 cell in SheetView when analyzed in the debugger seem to be having a kind of overloaded CultureInfo object, I do not understand why, my intension was just to have more decimal places for B3 cell.


     


    Thanks in advance,


    spm



  • Replied 8 September 2017, 1:16 pm EST

    Bob,


    Please let me know the status of the bug 22572.


    Thanks,


    spm

  • Replied 8 September 2017, 1:16 pm EST

    spm -

    I tested this and saw the behavior you did and then I retested it with the latest release of version 4 and the behavior is even more inconsistent so I will write this up as a bug.
  • Replied 8 September 2017, 1:16 pm EST

    Hi Bob,


       Thanks for quick reply.  I was wondering how quickly can I get the fix for this (any workaround would also suffice) and also how can I track this issue?


    Regards,


    spm


     

  • Replied 8 September 2017, 1:16 pm EST

    spm -

    The developer first has to determine if, in fact, it is a bug.  The project you sent was using a spread of version 2.5.  We will not be doing any more maintenance releases for that version so you would have to upgrade to version 4 to get the fix.  I do not have a timeframe for when that will be.  I know of no workaround at the moment.  The bug # is 22572.
  • Replied 8 September 2017, 1:16 pm EST

    Hi,


           Thanks for providing me the bug id, but I do not from where to determine the bugs progress.  Is there some web link where user reported bugs status are kept for reference.


    Regards,


    spm

  • Replied 8 September 2017, 1:16 pm EST

    We do not have status reports for bugs.  You can either post here or e-mail me via the forums for the status.
  • Replied 8 September 2017, 1:16 pm EST

    It has been written up as a bug and should be in the next maintenance release.
  • Replied 8 September 2017, 1:16 pm EST

    Hello Bob,


         Please let me know whether there has been any patch release for the Bug Id 22572, 


    regards,


    spm0      

  • Replied 8 September 2017, 1:16 pm EST

    It should be in the next couple of weeks.
  • Replied 8 September 2017, 1:16 pm EST

    This bug came back As Intended.  The developer's explanation follows...

    Our spreadsheet control is working as intended.



    In Excel, the user can assign the number of decimal places but the
    decimal separator character is always pulled from the current culture.



    In Spread, the user can assign a NumberFormatInfo object.  The
    NumberFormatInfo includes both the number of decimal places and the
    decimal separator character.  In other words, the user can not assign
    the number of decimal places with out also assigning the decimal
    separator character.



    In the provided example, the Excel file contained the following number formats...



        cell B1: General

        cell B2: Number (decimal places = 2)

        cell B3: NUmber (decimal places = 3)



    when this Excel file is loaded into Spread with current culture of
    English, the cells have GeneralCellType with the following
    NumberFormatInfo objects...



        cell B1: null

        cell B2: NumberFormatInfo (decimal places = 2, decimal separator = ".")

        cell B3: NumberFormatInfo (decimal places = 3, decimal separator = ".")



    Remember that the Excel file does not have a decimal separator but the
    Spread control needs a decimal separator in order to create the
    NumberFormatInfo to store the number of decimal places.  Thus, the
    Spread control pulls the decimal separator from the current culture at
    the time the Excel file is loaded.



    When you serialize to a binary file, the NumberFormatInfo objects get written to the binary file.



    Suppose you then change the current culture to Swedish.



    If you reload the Excel file (which contains no decimal separators)
    then the Spread control will pull all the decimal separators from the
    new culture settings.



    If you reload the binary file (which contains decimal separator for
    some cells) then the Spread control will load these decimal separator
    characters from the binary file instead of pulling these from the new
    culture settings.  Note that any cells that have a null
    NumberFormatInfo object would still pull the decimal separator
    character from the new culture settings at the time the cell is
    displayed.

Need extra support?

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

Learn More

Forum Channels