qax-os / excelize

Go language library for reading and writing Microsoft Excel™ (XLAM / XLSM / XLSX / XLTM / XLTX) spreadsheets
https://xuri.me/excelize
BSD 3-Clause "New" or "Revised" License
17.62k stars 1.68k forks source link

When calling `Save` more than once on an already formatted Excel, the values are saved on unexpected cells #1906

Closed DennyHecht closed 1 month ago

DennyHecht commented 1 month ago

Description

I have an empty Excel file I want to fill which contains cells with formatting. Now my application either calls a function which saves less data (one save call) or more data (more than one save call). In the first use case everything works as expected. In the second use case where my application has more than one save calls, excelize will save the values on unexpected cells. But only the values after the first save call are found on the wrong cells.

Steps to reproduce the issue:

  1. Open a formatted excel file
  2. Set some values and call Save()
  3. Set more values and call Save() again

Describe the results you received: After first Save() call the values are saved on unexpected cell. For example: Save a value on Z12 will save the value on AS12.

Describe the results you expected: Save a value on Z12 should be found on Z12.

Output of go version: tested with go1.22

Excelize version or commit ID:

v2.5.0 the bug exist <= v2.5.0 the bug doesn't exist

bug reason I could break down your code to https://github.com/qax-os/excelize/blob/5f583549f4cbbd33c7b143532fbccee4d3426653/excelize.go#L294

Before the first Save() call f.checked.Load will return false and than ws.checkRow will fill ws.sheetData.R.C with the missing cells. After the first Save() call f.checked.Load will return true and ws.checkRow will not be called. This is the reason why the SetCellStr will write on the wrong cell because only the formatted cells are found in ws.sheetData.R.C.

I attached you my sample project to reproduce the issue. I'm curious to here from you.

bug.zip

xuri commented 1 month ago

Thanks for your issue. This issue was introduced by commit d9a0da7 sheet.go:L170 in v2.8.1, the v2.8.0 works well. I have fixed it, please upgrade to the master branch code, and this path will be released in the next version.

DennyHecht commented 1 month ago

Thanks for the quick support!