For what it's worth, I'm using a build from last August.  The code changes
I'm seeing since then are almost entirely about API changes to use Enums
and ints and remove deprecated methods.

I'm suspicious there are not a lot of use cases where a document is opened,
edited, saved, edited again without re-opening, then saved again.  That's
where I'm seeing the sync issues, after the first save.  Then some
subsequent edits get lost.  it appears to be for cells that did not exist
originally, then were added by edits.  After the first save, edits to these
cells are not passed on to the CTRow, causing the second save to contain
incorrect data.  I'm still digging.

On Fri, Feb 23, 2018 at 11:09 AM Alain FAGOT BÉAREZ <abea...@for-scala.it>
wrote:

> Hi,
>
> It might have been the same symptoms which have led Sandeep Tiwari to make
> a code change that I was reluctant to accept in the branch about charts in
> XWPF. His explanations were in the line of yours. But I couldn't not accept
> the idea that such a fundamental feature had been broken.
>
> I hope to have some time this weekend to dive into the commits history to
> point out any change done recently that might affect that.
>
> Best regards,
> Alain FAGOT BÉAREZ
>
> ⁣
>
> Von: Greg Woolsey
> Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
> An: POI Developers List
> Betreff: baffling save behavior
>
> I hesitate to even bring it up, thinking I should be able to figure it out,
> but I've never seen behavior like this. Keep reading if you want to twist
> your brain in knots like mine.
>
> TL/DR - stop now if you'd rather be productive for your day job.
>
> Somehow, I have a consistent state where a file originating in Excel,
> modified through POI, then saved and opened in Excel causes not just an
> Excel repair, but incorrect/old data as well.
>
> So far, just a coding error, I figure. But the weirdness starts when I use
> the debugger to check on things. A specific row that I know comes out
> wrong has the right cell values when I use
> wb.getSheet(#).getRow(#).getCell(#).toString(), but when I check the CTRow
> and CTCell objects, then I find the old values still. So somehow, I've got
> the XSSFRow._cells collection out of sync with the CTRow _row contents.
>
> Anyone know how I could have done that?
>
> I may be calling workbook.write() in multiple places for different
> purposes/copies. It looks to me like XSSFRow.onDocumentWrite() explicitly
> replaces the CTRow array of CTCell beans with new ones due to bug, #56170,
> but it is replacing the CTCell references in the XSSFCell objects with the
> new copies, .
>
> I haven't found a smoking gun yet, but any thoughts are welcome. Perhaps
> the issue may lie with the formula evaluator created prior to the save
> event?
>
> It may be related to that bug, or even directly tied to it, as that was
> about updating tables, and that's part of the updates my process is doing
> as well.
>
> Sorry for the long document, normally I just figure these out on my own,
> but I've been at this a week so far, which has never happened before. If
> it comes down to black box behavior by XMLBeans, that would help explain
> it, as I know next to nothing about that library's details.
>
> Greg
>
>
> -------- Originale Nachricht --------
> Von: Greg Woolsey <greg.wool...@gmail.com>
> Gesendet: Fri Feb 23 03:53:08 GMT-03:00 2018
> An: POI Developers List <dev@poi.apache.org>
> Betreff: baffling save behavior
>
> I hesitate to even bring it up, thinking I should be able to figure it out,
> but I've never seen behavior like this.  Keep reading if you want to twist
> your brain in knots like mine.
>
> TL/DR - stop now if you'd rather be productive for your day job.
>
> Somehow, I have a consistent state where a file originating in Excel,
> modified through POI, then saved and opened in Excel causes not just an
> Excel repair, but incorrect/old data as well.
>
> So far, just a coding error, I figure.  But the weirdness starts when I use
> the debugger to check on things.  A specific row that I know comes out
> wrong has the right cell values when I use
> wb.getSheet(#).getRow(#).getCell(#).toString(), but when I check the CTRow
> and CTCell objects, then I find the old values still.  So somehow, I've got
> the XSSFRow._cells collection out of sync with the CTRow _row contents.
>
> Anyone know how I could have done that?
>
> I may be calling workbook.write() in multiple places for different
> purposes/copies.  It looks to me like XSSFRow.onDocumentWrite() explicitly
> replaces the CTRow array of CTCell beans with new ones due to bug, #56170,
> but it is replacing the CTCell references in the XSSFCell objects with the
> new copies, .
>
> I haven't found a smoking gun yet, but any thoughts are welcome.  Perhaps
> the issue may lie with the formula evaluator created prior to the save
> event?
>
> It may be related to that bug, or even directly tied to it, as that was
> about updating tables, and that's part of the updates my process is doing
> as well.
>
> Sorry for the long document, normally I just figure these out on my own,
> but I've been at this a week so far, which has never happened before.  If
> it comes down to black box behavior by XMLBeans, that would help explain
> it, as I know next to nothing about that library's details.
>
> Greg
>

Reply via email to