[Libreoffice-bugs] [Bug 86321] EDITING, FORMATTING: diagram didn't automatic update when change variable (steps in comment 28)

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Fri May 28 09:37:10 UTC 2021


https://bugs.documentfoundation.org/show_bug.cgi?id=86321

--- Comment #127 from Lars Jødal <lajo at rn.dk> ---
Using LO v. 7.1.3.2, i.e. current fresh version, on Win10, OpenCL active:

(In reply to VLB from comment #126, who uses steps from matthewnote comment
123)
> > Can you please use these steps?
> > Step 1.  Close actual work with Libreoffice (Writer or Calc)or restart
> > computer.
> > Step 2.  (Important to follow) Start Calc but do not open any other file.
> > Step 3.  Open only the attachment, only file Ligger V2.6 attachment 114246 [details]
> > [details]
> > Step 4.  Go to sheet invoer.
> > Step 5.  Use mouse to Select H19 to L19. Those cells now highlighted.
> > Step 6.  Use keyboard (important) delete key to empty those cell values.
> > Step 7.  Observe column EB; most cells EB50 to EB148 change to WAAR.
> > Step 8.  Observe chart at M66; the traces change to sawtooth.
> > Step 8.  Use mouse (important) toolbar "back arrow" to "Undo:delete".
> > Step 9.  Observe column EB; the cells do not go back to original state.
> > Step 10. Observe chart at M66; one line (for DT data) does not go back.

Upon opening: I reject macros.
Checking the column EB before doing anything: A few cells show WAAR. After the
deletion: most cells show WAAR, as described in step 7.

On step 9: I can confirm that after undo from menu, column EB has not changed
back to how it was.
On step 10: I can confirm that in the cart at M66, one curve (representing data
from the DT column) is partly flat and near the horizontal axis, rather than
being sawtooth, and this curve represents data from the DT column.

In short, I can confirm the strange behaviour reported in steps 9 and 10.

> > [At this stage, something complex is occurring in the memory;  please don't
> > touch any cell or chart or data range;  please just observe and compare to
> > help me help you].
> > 
> > Step 11. Close Libreoffice (close the program) and do not save the file.
> > Step 12. Start Libreoffice and open only the attachment, only file Ligger
> > V2.6
> > Step 13. Go to cell AM38.  Function is ==IF((L_7>0),Mh/Mh_freq,"")
> > Step 14. Change the function to =IF((L_7>0),Mh/Mh_freq,""), remove double==
> > Step 15. Immediately save the file as "Ligger V2.6 test repair by VLB.ods"
> > Step 16. Close Libreoffice (close the program)
> > Step 17. Start Libreoffice and open the new test repair file.
> > Step 18. Please test using Step 4 to Step 10.

After the repair (double== to single= in cell AM38 of "invoer" sheet, save,
close LO, and then steps 4-10 on the repaired file), undo appears to work
fully. 
I.e., I can confirm that the double== made LO have strangely.

Version information:

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: CL

No user profile reset.
OpenCL active.

Bonus information: If I de-activate OpenCL (and start with the original file,
of course), then I cannot reproduce. Re-activating OpenCL, I can again
reproduce. This confirms the part of comment 123 that ties the behaviour to
OpenCL.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210528/172175eb/attachment.htm>


More information about the Libreoffice-bugs mailing list