Edit mode changed something regarding the paint in the recent releases

Edit mode changed something regarding the paint in the recent releases

Posted by: davide.vago on 28 June 2021, 5:49 am EST

• 

  davide.vago

  • Post Options:
  • Link
    Copy
  • Jump To Answer

  Posted 28 June 2021, 5:49 am EST - Updated 3 October 2022, 9:43 am EST

  Dear support,

  I’m reaching you out as in the recent releases from 14.0.10 to 14.1.1 something changed within the edit mode, it seems like the isPaintSuspended() returns always true even after a resumePaint() gets programmatically triggered.

  We use a customization of the edit mode to highlight with a different colour what changed from the initial data. It appears that as soon as we swap the cell style with the “edited” version we start experiencing an overlay of the previous data once re-entering in edit mode.

  Please look at the screen record in attachment
  
  

  The change made on your side also affects several other functionalities so I need to understand what it changed on the paint flow and the related programmatic way of suspending and resuming.

  Just to give you an idea of what we do during the editing mode:

  CellChanged event checks if the previous and new value aren’t the same, the propertyName is not ‘value’ or ‘formula’ and if the check is met, then we get the current style via getActualStyle method and merge this style with our foreColor then reassign to the cell the style via setStyle method. During the last few days of debugging I also tried to skip the merge of the style and simply getCell and assign foreColor(mycolor).

  The same logic applies on RangeChanged when the info.action is 0,1,2,3 to cover cases like: Undos, Dragfill, clear (from an Undo)

  Either way, the issue is deeper and outside my visibility since your library is compressed and has no debug mode.

  Would you please look into it and/or release more information about the latest few changes your devs did around this area?

  Looking forward to hearing from you

• 

  avinash.pathak

  • Post Options:
  • Link
    Copy

  Posted 29 June 2021, 4:24 am EST

  Hi Davide,

  We are sorry but we are unable to replicate the issue at our end. Also, resume paint does not always guarantee the paint to be resume. Actually internal it is implemented as a stack so when the number of resume and suspend Paint calls are equal(then mean when the internal paint suspendPaint stack get empty) then only SpreadJS resume Paint. So make sure you have made an equal number of suspend/resumePaint calls.

  Further, if the issue persists please share a small sample that replicates the issue so that we could investigate it further and assist you accordingly. You may also refer to the following sample that we used for testing and modify it to replicate the issue.

  sample: https://codesandbox.io/s/lively-dream-wxkjl?file=/src/index.js

  Also for getting the list of changes made in the release you may refer to the following link:
  
  https://www.grapecity.com/my-account/devchannel

  Regards
  
  Avinash

• 

  davide.vago

  • Post Options:
  • Link
    Copy

  Posted 29 June 2021, 5:55 am EST

  Hi Avinash,

  Would you mind create me a snippet which does change the text color of the cell that gets edited/pasted.

  I noticed that setStyle does create problems like: the formatter of the cell gets wiped out and/or the paint flow gets funny.

  Thanks in advance
  
  Davide

• 

  avinash.pathak

  • Post Options:
  • Link
    Copy

  Posted 30 June 2021, 7:44 am EST

  Hi Davide,

  Please refer to the following sample that demonstrates the same functionality and if the issue persists please modify the sample to replicate the issue so that we could investigate it further and assist you accordingly.

  sample: https://codesandbox.io/s/solitary-platform-4whtr?file=/src/index.js:274-655

  Regards
  
  Avinash

• 

  davide.vago

  • Post Options:
  • Link
    Copy

  Posted 30 June 2021, 9:25 am EST - Updated 3 October 2022, 9:43 am EST

  Thanks Avinash,

  This is quite similar to what we had in the past, I tweaked your code to have a bit more flexibility because the sheet comes with his own data, which some times has style per cell and sometimes it doesn’t. That’s why you will notice I’m using getActualStyle rather than getStyle as I might have just cells with a null returned by the getStyle method, meanwhile the getActualStyle returns a style no matter if it’s applied at the cell level or at the root.

  https://codesandbox.io/s/kgnug?file=/src/index.js

  Look at this bug, maybe you will be able to give me fix:

  

  Thanks

• 

  avinash.pathak

  • Post Options:
  • Link
    Copy

  Posted 1 July 2021, 4:42 am EST

  Hi Davide,

  Thanks for the sample. We are able to observe the same at our end hence we have escalated this issue to the concerned team for further investigation. We will update you regarding this issue as get any information from the team. The internal ID for this issue will be SJS-9126.

  Regards,
  
  Avinash

• 

  avinash.pathak

  • Post Options:
  • Link
    Copy

  Posted 5 July 2021, 12:33 am EST

  Hi Davide,

  The Devs informed us that the issue is Object.assign to compose two styles, which makes the style id messed internally.

  For simple workaround

  function changeStyle(sheet, changedRange) {
      sheet.suspendPaint();
      sheet.suspendEvent();
      console.log("changing style of the range", changedRange);
      changedRange.forEach((range) => {
          const { row, col, rowCount, colCount } = range;
          for (let r = row, rLen = row + rowCount; r < rLen; r++) {
              for (let c = col, cLen = col + colCount; c < cLen; c++) {
                  const currentStyle = sheet.getActualStyle(r, c);
                  let baseStyle = new GC.Spread.Sheets.Style();
                  baseStyle.fromJSON(changedStyle.toJSON());
                  const newerStyle = Object.assign(currentStyle, baseStyle);
                  sheet.setStyle(r, c, newerStyle);
              }
          }
      });
      sheet.resumePaint();
      sheet.resumeEvent();
  };
  

  Regards
  
  Avinash

• 

  davide.vago

  • Post Options:
  • Link
    Copy

  Posted 19 July 2021, 6:20 am EST

  Thanks Avinash,

  Does it mean we might expect a library fix which will permit us to remove the provided workaround?

  Looking forward to hearing from you
  
  Davide

• 

  avinash.pathak

  • Post Options:
  • Link
    Copy

  Posted 20 July 2021, 1:46 am EST

  Hi,

  Since the issue is not related with the spreadJS and workaround is working properly hence it will not be included in future release. Please let us know if you face any issues while using the following workaround.

  Regards
  
  Avinash