[Libreoffice-bugs] [Bug 86321] EDITING, FORMATTING: diagram didn't automatic update when change variable (recalculation not triggered)

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Wed Sep 23 10:42:29 UTC 2020


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

--- Comment #48 from matthewnote at yahoo.co.uk ---
This problem is also consulted on "Ask LibreOffice" since Calc 4.4.3 2015.
https://ask.libreoffice.org/en/question/53027/chart-does-not-update-when-cell-content-change/

Alex Kemp closed it as "not relevant or outdated".  No idea why.  So the users
go away from LibreOffice or a few come here.

This Bug and Bugs #136254 #136160.

Update.  The sample file from me has received further testing.
1.  Someone else's PC with Apache OpenOffice 4.1.1 (2014) on Puppy Linux.
Result.  Chart fails to update when a cell value is changed.

2.  Apache OpenOffice 4.1.7 (2019) on Puppy Linux.
Result.  Chart fails to update.

3.  LibreOffice Calc 6.4.5.2 on Ubuntu Fossa 20.04 (Linux 5.4).
Result.  Chart fails to update.

4.  Calc 7.0.1.2 package 1:7.0.1-0ubuntu1_oibaf~f installed by automatic
upgrade on same Ubuntu Fossa 20.04.
Result.   Chart started working!  File saved.

5.  Opened the saved file from Fossa PC on a different PC.
Calc 6.3.5.2 (1:6.3.5~rc2-0ubuntu0.18.04.1~lo1) on Ubuntu 18.04 (Linux 4.15)
Result.  The new sample file seen to work once on Fossa - not working here.

6.  Update computer to Calc 7.0.1.2 (package 1:7.0.1_rc2-0ubuntu0.18.04.1)
Result.  The new sample file that works on Fossa - works here too.  Chart
updates.

7.  The original broken file (attached to this Bug report) opened on the Ubuntu
18.04 computer as at test 6 using Calc 7.0.1.2.
Result.  The old sample file (broken) now works.  Chart update.

Implications.  It seems possible to find a system configuration that will load
a file with broken charts causing them to "work".   That saved, the "possibly
repaired" file can be used on the computer with all-loads-fail (including safe
modes) and it works there.   Then, very surprising, the computer with
all-loads-fail can open it's own original (broken) file and use it.  Can
computer B teach computer A how to load charts correctly?

8.  This implication was tested using a much larger file (102 MB).
Result.  On the Ubuntu 18.04 and Fossa 20.04 computer with 7.0.1.2, none of the
24 charts update with data changes;   none at all.

9.  With that large file, one of all the paralysed charts was copied and pasted
on the same sheet side by side.   The twin autoupdates with cell value changes.
It's original remains "off".

Further testing.  At some stage I have to get back to Cancer or leave
LibreOffice.  What I will do is attempt to recreate the whole 102MB file.
Some users report that they "feel" reconstructing a file helps clean out
"something".  By opening a new sheet and building it up using "Insert Sheet
from File" they find the result is small than the original source.  It's a
laborious sheet by sheet procedure with new problems, including the insertion
causing External Links even though the Ext Links is deselected.  Yet it's
possible to get through with checking every single cell (or by search) and
editting out false linking.  I did this routine this year once with one file
and it seemed to help yet I couldn't finish the job;  large file saving caused
Calc 6.3.4 crash (linux disk cache going up gradually to 5.5G then Calc crash
at 5.6G every time).  Also copying one near empty sheet required 8 to 9
minutes.

With LO7.0.1.2 copying a sheet of only numbers is done in five seconds and
saving a large file works every time (so far since one month).  Great!  So I'll
stick with it, contribute some more and hope Xisco is being informed.

-- 
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/20200923/f187da1e/attachment.htm>


More information about the Libreoffice-bugs mailing list