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

Thu Oct 1 07:05:01 UTC 2020

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

--- Comment #57 from matthewnote at yahoo.co.uk ---
(In reply to Lars Jødal from comment #56)
> Interesting. I tested attachment 165696 [details] on two different
> installations (on two different computers, both running Win10), running the
> current "still" and "fresh" versions of LO. More details below, but the
> result was that update did NOT work on LO 6.4.6.2, while update DID work on
> LO 7.0.1.2.
> 
> Test file: matthewnote's attachment 165696 [details]
> 
> Doing what: Cell L259 on sheet "The SWITCHexpanded" contains the number 17.
> Changing 17 to 25 should give a visible change to the XY plot covering about
> C283 to P341 (based on description in comment 46).
> 
> Results with LO 6.4.6.2: Changing 17 -> 25 gives no visible effect.
> CTRL-SHIFT-F9 does not change that. Double-clicking on the diagram does give
> the effect (points move to a different configuration), but it is reversed
> when focus leaves the diagram. Conclusion: Update does NOT work.
> 
> Version: 6.4.6.2 (x64)
> Build ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
> CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: default; VCL: win; 
> Locale: da-DK (da_DK); UI-Language: en-GB
> Calc: threaded
> 
> Results with LO 7.0.1.2: Changing 17 -> 25 changes the plot within a
> fraction of a second. Conclusion: Update DOES work.
> 
> Version: 7.0.1.2 (x64)
> Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452
> CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL:
> win
> Locale: da-DK (da_DK); UI: da-DK
> Calc: threaded
> 
> @matthewnote: I will email you a saved version of the file. Have you tried a
> user profile reset?

Thankyou Lars

Yes, I've been doing all Safe Modes.   Specifically, only one file here (of
about three hundred) updates charts and I'm unable to cause any of them to
break (for the moment, yet only for that file).  How did that happen?  I was
creating spreadsheets with versions up to 6.4.5.2 (the Ubuntu 18.04 Bionic
Beaver tested companion LibreOffice versions upgrade about every three months
that they recommend as "conservative").   All work had broken charts after a
day or a week.  So I tried out reconstructing a large file by starting a new
ODF and  sheet by sheet "Insert sheet from file" (from faulty file to fresh
start).  A type of "importing" to build up a new one.   Still unsuccessful.  A
message circulated on the web that a Ubuntu 18.04 conservative user could ppa
install LO 7.0.1.2 and purge it out to the default "official" LO 6 if necessary
(go-back possible).   Nothing to lose so I did that.  The install overwrites a
lot yet completed just fine.

First try with the fresh file under reconstruction using LO 7.0.1.2 and all
charts worked.  All of them.  Amazing. My first and only ever.  So, I tried to
rescue another key file of the project here the same way, identical procedure -
and none of the charts worked, none at all.  All safe modes explored.  

To test the possibility "Upgrading to LO 7 gives you one shot with one file to
cause one repair" I purged LO 7, restarted Linux with 6.4.5.2;  then restart
again, then re-do the ppa LO 7.  Same message "Welcome to LO 7 - did you know
etcetera" apparently with a fresh user profile.   However it didn't cause the
second file to repair and run correctly.   There's a possibility that if I wipe
the workstation disk or attempt a dual boot to a separate partition and go up
through the procedure again, perhaps I can get "one more success" for one more
file.  However, for the moment I'm exploring files by unzipping them and
reading their .xml

I have found one significant difference with the only
stable-always-working-charts-update file.  Unzipping the .ods, reveals that it
has a folder that my other files lack.  \ObjectReplacements.  In that folder
there is a binary file for each and every chart object listed in the manifest
(META-INF/manifest.xml).  The binaries (that apparently came from nowhere) are
Type STL 3D model (binary) (model/x.stl-binary) according to Linux.  Never
heard of it.  The total folder content is 124 MB (the contents of that folder
unzipped) which is very light.  Once the file is opened (takes 7 GB of RAM) I
don't see a significant increase in use of memory.

The manifest.xml of the fully working file also has a difference.  It points to
that extra folder ;
full-path="ObjectReplacements/Object n"
manifest:media-type="application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile""
None of the broken files have that xml manifest entry.

None of the broken files have that folder.  Most of them are listing
manifest:manifest
xmlns:manifest="urn:oasis:names:tc:opendocument:xmlns:manifest:1.0"
manifest:version="1.2"
xmlns:loext="urn:org:documentfoundation:names:experimental:office:xmlns:loext:1.0">
 <manifest:file-entry manifest:full-path="/" manifest:version="1.2"
manifest:media-type="application/vnd.oasis.opendocument.spreadsheet"/>

yet a few broken files state they're configured for manifest:version="1.3" (the
latest).  The only fully working file uses "1.3" also.

So I continue to search to learn about ObjectReplacements Chart binaries and
how they got there.  I've read other users gave up trying to find out more
about that subject.  Perhaps a programmer knows immediately what that's all
about.

Tomorrow I'll be inspecting the file you returned to me having passed it
through a Windows build.  (I'm going to a hospital today).

Matthew

-- 
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/20201001/b8ede549/attachment.htm>