I have more sheets and when i change the variabele then is only the graphic on the first sheet automatic update and not the adere graphic's on the other sheets.
Created attachment 109539 [details] Issue graphic
(In reply to vlb from comment #1) > Created attachment 109539 [details] > Issue graphic When it is reproduce: Look ad graphic's in sheet "invoer" cel A57:S80 and sheet "vb_610a" cel A46:S66 Go to sheet "invoer" cel g19 and when i put 5 in this cel there isn't change the graphic on sheet "vb_610a".
Please provide much clearer reproducible steps (that are enumerated). Example: 1. Do X, 2. Do Y, Expected result.... With the given information there is not enough information for us to reproduce. Marking as NEEDINFO. Once you clarify please mark as UNCONFIRMED. Thanks
I try to explane the issue: The issue isn't always present. Today i try again and it works, but not always. To reproduce: 1) place value "5" in cel invoer.G19 2) then in graphic M-lijn in cel invoer.L56:s63 you see tree triangels 3) when you delete the value "5" in cel invoer.G19 4) then in graphic M-lijn in cel invoer.L56:s63 you see two triangels (this is correct working) 5) in graphic "momentenlijn" in cel vb_610a.E51:N55 must do the same as in step 3 and 4 6) sometimes the graphic isn't change and see i two trangels, also when i have do step 3 7) When it doesn't work correct and i click on the graphic, than is the graphic change in tree trangels. But when i go out of the graphic i see two triangels in graphic on sheet "vb_610a". 8) When i have change someting in the graphic, then it is mostly action In a other sheet when i have a graphic Chart type xy (scatter) with the same as step 2 and i have copyd to a other sheet and make for x-as/y-as a range values it make the range as Chart data Table with fixed x/y values in lieu of Data Range. I hope this helps.
I have test in LO 4.4.0.0 beta 1 and ther is the same issue. Some graphic are updated when the valeue's are change and some graphics didn't update.
Referring bug 86572 and do hard recalc CTRL+SHIFT+F9 than the graphic is oke.
*** Bug 86572 has been marked as a duplicate of this bug. ***
Problem with automatic recalculation.
(In reply to raal from comment #7) > *** Bug 86572 has been marked as a duplicate of this bug. *** Bug 86572 are the value's not recalculation only in LO4.4.0.0beta1 and are correct calculation in LO 4.3.4. Bug 86321 are the graphic's not recalculation in LO4.3.4 and LO4.4.0.0beta1.
(In reply to vlb from comment #9) > (In reply to raal from comment #7) > > *** Bug 86572 has been marked as a duplicate of this bug. *** > > Bug 86572 are the value's not recalculation only in LO4.4.0.0beta1 and are > correct calculation in LO 4.3.4. > Bug 86321 are the graphic's not recalculation in LO4.3.4 and LO4.4.0.0beta1. I have test in daily build Version: 4.5.0.0.alpha0+ Build ID: 5c3f47e44c2a734bddd0c3fb7f1151d5096ac494, because bug 86615 is solved. But the bug isn't resolved for this!
(In reply to vlb from comment #6) > Referring bug 86572 and do hard recalc CTRL+SHIFT+F9 than the graphic is oke. It didn't work always with hard recalc CTRL+SHIFT+F9, sometimes you must save the file and when you open the file again, the graphic/chart is oke.
MAB => highest (see https://bugs.freedesktop.org/show_bug.cgi?id=84480)
*** Bug 87383 has been marked as a duplicate of this bug. ***
I have experienced this bug also. As Workaround, I simply move the chart into another position. Regards
This is not a critical bug - I'm not sure who marked it as such. Marking as: Minor - there is a workaround (see last comment). It can slow down professional quality work but will not prevent it. Critical is reserved for major crashes and serious data loss - this is neither. I'll leave as highest and leave it on MAB list. Please do not revert my changes. What would be nice is for those seeing this issue to test older releases to see if it's a regression. http://downloadarchive.documentfoundation.org/libreoffice/old/ Best thing to do is to test 3.3 - if it's present in 3.3 then it's not a regression (please leave a comment). If it isn't present in 3.3, then start testing every release (3.4, 3.5, 3.6, 4.0, etc...) to try to narrow where the bug came in.
Created attachment 114246 [details] Latest Issue graphic I have test the issue in the version Lo 3.5+3.6+4.0+4.1+4.2 and works the graphic correct. In LO 4.3.0 is the first version where the issue present. I have a new attachment where the issue is present. In the latest attachment you can reproduce the issue: 1) open attachment "Latest Issue graphic" 2) see the graphic in sheet "invoer L58:s64"+"vb_610a A51:p56"+"vb_610b A51:p55"+"eg A51:p55"+"loX0_9 A52:p56"+"roX0_9 A52:p57" 3)delete cell H19:l19 4) The graphic on "rox0_9 A52:p57" isn't update 5) When you double click on the graphic "rox0_9 A52:p57" you can see the correct graphic 6) When you go out the graphic the graphic isn't correct update
I hope the issue can solved.
Woul now be nice to get a bibisect of the bug - https://wiki.documentfoundation.org/QA/HowToBibisect If you need help - feel free to jump into the QA Chat: http://webchat.freenode.net/?channels=libreoffice-qa
Bibisect results from 43all: (Just a whisker before 4-3-branch-point...) ea5723ff672d4a3ffb9ee123a96dda4681703a50 is the first bad commit commit ea5723ff672d4a3ffb9ee123a96dda4681703a50 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Wed May 21 08:57:55 2014 +0000 source-hash-1b8cfd5d1414da9127ff18e4701b40f5bceabb36 commit 1b8cfd5d1414da9127ff18e4701b40f5bceabb36 Author: Markus Mohrhard <markus.mohrhard@collabora.co.uk> AuthorDate: Tue May 20 23:59:55 2014 +0200 Commit: Markus Mohrhard <markus.mohrhard@collabora.co.uk> CommitDate: Wed May 21 01:50:44 2014 +0200
Following the instructions in Comment 16, this works for me again since commit 8d509d69b434bd70b61cb6eed8b8dc21707726a3 Author: Zolnai Tamás <tamas.zolnai@collabora.com> AuthorDate: Mon Aug 11 14:27:16 2014 +0200 Commit: Markus Mohrhard <markus.mohrhard@collabora.co.uk> CommitDate: Fri Aug 29 17:40:29 2014 +0200 This OpenGL window is useless Change-Id: Ied9914c9a317dc3945c29b984d2a68957275fc52 After this commit, the indicated chart updates after step 3, with no manual recalculation required. LO 4.4.2.1 also works as expected. I also tested a build of 5c3f47e44c2a734bddd0c3fb7f1151d5096ac494 as mentioned in comment 10, and the chart updated as expected there too. @vlb: - Please check that you are testing with the version you think you are - all other running copies of LibreOffice should be closed first. (The running version can be checked with "Help – About") - If that doesn't work, please try following the instructions in https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile - If that still doesn't work, please feel free to reopen this bug, confirming the latest exact version upon which you see an issue, the platform upon which you see it, and the steps followed to reproduce the issue (if the same as in a previous comment, just mentioning the comment number would be sufficient) As it appears to me to be fixed, I am closing this bug for now. -> RESOLVED FIXED (a specific commit has been identified, and doesn't mention another bug ID to close this bug as a duplicate of)
> @vlb: > - Please check that you are testing with the version you think you are - all > other running copies of LibreOffice should be closed first. (The running > version can be checked with "Help – About") yes i have test with the latest version LO 4.4.1.2 > - If that doesn't work, please try following the instructions in > https://wiki.documentfoundation.org/ > UserProfile#Resolving_corruption_in_the_user_profile I have done but didn't work by the steps comment 16
> After this commit, the indicated chart updates after step 3, with no manual > recalculation required. LO 4.4.2.1 also works as expected. > I also tested a build of 5c3f47e44c2a734bddd0c3fb7f1151d5096ac494 as > mentioned in comment 10, and the chart updated as expected there too. I have also test in LO 4.4.2.1 Build ID: 93fc8832889bf050a10ec6d0171dae213adc9b55 and here is the same problem, by do the steps in comment 16!
@vlb: Could you let us know what platform (OS) and version you're using Thanks
(In reply to Matthew Francis from comment #23) > @vlb: Could you let us know what platform (OS) and version you're using > Thanks I use windows 7 Professional servivce pack 1 64-bits i7 and 4GB RAM
(In reply to vlb from comment #22) > I have also test in LO 4.4.2.1 Build ID: > 93fc8832889bf050a10ec6d0171dae213adc9b55 > > and here is the same problem, by do the steps in comment 16! Hi Frank, I confirm the behavior that you mention. 1. Double click the diagram on "rox0_9 A52:p57" It is still the same. 2. Leave the diagram and delete cell H19:l19 The diagram is still the same 3. Now again double click the diagram on "rox0_9 A52:p57" It changes 4. Leave the diagram It returns to the previous state. However, may be me, I fail to see the logic of the diagram, having the data ranges $roX0_9.$U$9:$V$18;$roX0_9.$CS$3:$CS$153 (you may mail me and explain in Dutch what is going on, if you prefer.) thanks, Cor
(In reply to Cor Nouws from comment #25) > I confirm the behavior that you mention. on Ubuntu 32 bits > 2. Leave the diagram and delete cell H19:l19 on sheet *invoer*
Created attachment 114419 [details] Screenshot from rox0_9 after deletion in invoer H19:L19 1) Went to sheet invoer 2) Deleted contents of H19:L19 3) Went to rox0_9 and took this screenshot Decide for yourself. At least the chart was updated immediately after deletion of data without me doing any double-clicking. Win 7 Pro 64-bit, LibO Version: 4.4.1.2 Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432 Locale: fi_FI
OK, so I see what I did wrong before. The already fixed bug I mentioned in comment 20 was for the chart in the "invoer" sheet, which works in 4.4 already The issue I now see was meant is for the "roX0_9" chart, and is reproduced as follows: 1. Open attachment 114246 [details] 2. Go to sheet "roX0_9" 3. Go to sheet "invoer" 4. Delete H19:L19 5. Go back to sheet "rox0_9" The diagram at A52:57 has not updated, but shows the updated values when edited. Note that the bug does not reproduce if step 2 is skipped.
The remaining issue also appears to have been fixed, in the below commit: commit dc28e90d200a839d4017d548217ee5ce8a23f848 Author: Noel Grandin <noel@peralex.com> Date: Thu Dec 25 15:17:55 2014 +0200 fdo#84938: convert IMPORT_ constants to 'enum class' Change-Id: Idaa8f07c62b3ba93c27ca5fe286720254baac10d From examination of its content, it's clear why this may be the case. However, this commit also possibly didn't intend to fix anything - it looks like it was supposed to be just a refactoring. Assigning to markus.mohrhard@googlemail.com by his request for further investigation as to whether this fix is correct.
(In reply to Beluga from comment #27) > Decide for yourself. At least the chart was updated immediately after > deletion of data without me doing any double-clicking. The chart on "rox0_9 A58:p62" , but not the one on "rox0_9 A52:p57"
*** Bug 90083 has been marked as a duplicate of this bug. ***
*** Bug 90674 has been marked as a duplicate of this bug. ***
*** Bug 87622 has been marked as a duplicate of this bug. ***
please give an update of the current bug status with latest 4.4.x or master builds. if issue is definitively gone let's finallly close this. if some problem persists I suggest to close this report anyway since it's getting hard to follow it (many comments and many different steps to reproduce) and start again from scratch with a new clean bug report
(In reply to tommy27 from comment #34) > please give an update of the current bug status with latest 4.4.x or master > builds. I have take the steps in comment 25 with attachment "Latest Issue graphic" with LO 4.4.4.2 and the graphic didn't correct update. When i use LO 5.0.0.2 for the attachment is the graphic correct update, but when i use a other sheet the graphic didn't update. It isn't a constant issue and make it diffecult. > if some problem persists I suggest to close this report anyway since it's > getting hard to follow it (many comments and many different steps to > reproduce) and start again from scratch with a new clean bug report Because the update graphic isn't constant it's defficult make a good example. I hope it is solve the issue here.
*** Bug 91931 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Dear developer, This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW. Please assigned it back to yourself if you're still working on this.
A patch proposed for bug 31231 (https://gerrit.libreoffice.org/44396) will revert the change that was reported to fix things here (in comment 29).
This doesn't even seem to be a Calc problem, one can as well directly modify the values in the chart's (Object 15) data range $roX0_9.$U$9:$U$18 (i.e. set U13:U18 to 8 which is the same value as when deleting invoer.H19:L19, or any other value fwiw) and the chart does not update. BUT, double clicking it reveals the updated chart according to the values. Leaving the chart again displays the old values. Also modifying the data ranges for data series 'Column V' doesn't change that. Something seems to be broken with the chart view representation (old replacement/preview view used?).
I have test with the latest version LO 6.0.0.0beta 2 and it is still present.
I have test in Versie: 6.0.4.2 (x64)and is still present.
Charts not updating (x, y scatter plots) is still present in Version: 6.0.6.2 Build ID: 1:6.0.6-0ubuntu0.18.04.1. Usually, when a column is recalculated there's a leap in processor use (CPU 100% for three seconds) as the graphic engine presents the fresh image of charts concerned. When the chart appears to be "broken", the data column modifies, yet not the charts and the CPU remains at idle. For 100 x,y scatter plots here, after an hour of data work, about half the charts are inert, not moving - and you don't know which except by inspecting all of them. Clicking on one of the charts then dragging it a few pixels - only that chart updates (comment 14) so it takes an hour's work for one digit change. If the user zooms by menu or Ctrl+mousewheel out then back in, the whole screen including all charts visible update to the new values. It's a faster workaround and may help learn what the bug is? For each data change it's necessary to zoomin/zoomout again. Very surprised to see this marked as importance "minor". Closing and reloading Calc in safe mode brings all charts back to life (autoupdating) yet it's impractical to do that thirty or fifty times a day. I've tried every safe mode too. I volunteer for user debug work using this system if it helps.
The bug is in LO Versie: 6.3.2.2 (x64)still present.
Created attachment 165696 [details] Calc file with simple XY scatter plots that neither update nor rescale.
This Bug is still present in LO Calc 6.3.4 LO Calc 6.3.5.2 (using OS Ubuntu 18.04 LTS) LO Calc 7.0.1.2 (also on Ubuntu 18.04 LTS) All safe modes tried. LO reinstalls also. For Joel. This is proving very difficult to provide a "method" to create a broken X,Y scatter diagram. In four years I've not yet been able to cause it deliberately step by step. So I contribute a sample file with broken graphics (an early learning file not intended for presentation). General situation description. Inserting an X,Y scatter chart, the plotting updates for a few days work and follows new results in it's Data Range cells, then abruptly stops updating. Sometimes it's a graph done at the start, sometimes it's only a copy, sometimes it's both, then half of all graphs stop updating. Sometimes reopening the file gives the user one more operation, you can watch the result of a number change on the plot, yet only once. The workload to continue using the file is huge. Here there are now three or four hundred files (Cancer data) based on about five general structures and (as of January 2017 to September 2020), regrettably, only one has all graphics following data input changes. Calc 7.0.1.2. I was able to use a file more than twice. Testing Calc 7.0.1.2 with another near identical file (recently modified using 6.3.5.2) of the same size too, that second file opens and none of the X,Y scatter plots update, none at all. Never seen that before either (all plots broken after File>Open). (Usually some plots keep updating occasionally then break and never repair.) This is else than "minor"; the workload is crushing. Reason. Unfortunately a bug report moderator considers that autoscale on the Y axis doesn't need to function correctly for X,Y scatter (although users are desperate to have it function the same as autoscale X axis and write macros to try to do what the moderator refuses). When the data preparation for a graphic changes from y values to LN(y) values (for example), you not only have half or more than half the plots don't update at all - If you double click on any, the new presentation will jump and show the Y values squashed at the top. If you go back to click a cell on the sheet (for example to change a 1.0 to a 1.1) all the plots go off again to the old values. Moving or rescaling all the plots to cause one update to be shown once - well, I spent about two months of the twelve in 2019 only doing that, sometimes collapsing with exhaustion. Why is autoscaling for technical users important? The sample file has very many plots. The actual Cancer data work chooses to make only a few plotters to minimise the processing load. On it's sheet, that plotter fetches or reads the data from columns. Those columns are indirect adressing so that the user selects the data sheet name for X axis and another data sheet name for Y axis. That way, there can be fourty simple sheets of numbers and only one X,Y plotter is needed. Note: One screenshot or copy of one plot for a slide presentation using histogram style autoscaling or forcing a manual Y axis scale may be the intention of some Calc users or administration staff. It's unusable for investigation work. For Xisco Pauli. Please assign this subject to someone "technical" rather than "presentation". Personally I only ask Calc to use +, -, *, /, LN() and EXP() then plot. I can exhaust myself yet feel unable to share any of the four years work. I stay with LibreOffice with some sort of confidence that it will work out. (As a Raytheon real-time software testing engineer you learn to share Bug information without worry and never ever put down the user point of view as trivial or minor. That attitude is absent, so, well, without effort to not do it either) :). Therefore I add a sample file. Although it were best to prepare a smaller file, I've tried trimming and deleting sheets with new problems every occasion. LO 7.0,1.2 purged, LO 6.3.5.2 default for Ubuntu 18.04 installed. Opening sample "BMI BM BMH switch expt10.ods" displays sheet "TheSWITCHexpanded". X,Y scatter (reading columns P,M,D) is on the area C283 to P342. Cell L259 multiplies x values for that scatter diagram (default value is 17). Step one. Click on L259, enter 25. Result. The graph below fails to update. Expected result. The plot moves red and violet points to the new x positions. Step two. Clickandhold on the frame of the graph, dragging it one or two pixels. Release the mouse button. Result. The graph updates to the new data. Step three. Double click the plot itself and change Y axis scaling to autoscale. Result. The y axis scale changes to 0 <-> 45 with all data squashed in the top third. Expected result. y axis autoscale perform precisely the same as x. This is very important for technical use of any data. x values same as y values should always produce a linear trend line to an origin of (x,y) where x and y are identical too. Step four. Click again once on any cell to quit the graphic. Step five. Double click the plot and change Y axis scaling to manual 15 <-> 45. Result. The plot adopts the new scale. Step six. Click on any cell to quit the graphic. Result. The plot displays Y axis scaling on 25 <-> 45, ignoring the user entries. Expected result. The manual scale 15 <-> 45. Step seven. Clickandhold on the frame of the graph, dragging it one or two pixels. Release mouse button. Result. The plot updates to the user requirement (but only once). Expected result. Plot updates to any of it's Data Range cell changes always. My thanks. Calc 6.x.x.x and 7.0.1.2 plots are astounding quality. I use 4K monitors; the antialising is brilliant and the scatter plots with trend lines surpass all other software used here (Paraview, Scilabs equivalent Matlab). Ubuntu 18.04 is rock solid (thanks to choosing Gnome) and Calc 7 is marvellous. If someone wishes to see a Cancer data analysis user file with the indirect addressing and all X,Y scatter plots (suddenly) working (to have a look at a technical/scientific use of Calc - where it can go), I have one file that works. It's 102 MB, uses external links to files of 30 MB more and runs quite comfortably on a Kaby Lake 3.6Ghz 16GB desktop. Calc is very impressive software. Sometimes I just sit and think about the talent. Thankyou.
Importance: I agree that trustworthy updating of plots is important, especially if you work with many plots. A few years ago, I used LO for my Ph.D. project, and it was huge problem to me that plots very often did not update - I did not know which plots I could trust, and there were a lot of them, so a workaround of moving all plot a few pixels each was very unattractive. (But yes, I kept using LO, and I am still a user.) Pinning it down: Like matthewnote writes, it is not an issue that is easy to pin down. I have mostly experienced it with many plots, something many users are not going to do. Status of the bug? I just tested matthewnote's sample file, attachment 165696 [details], using LO 7.0.1.2 on Win10. Interestingly, the plot does seem to update immediately (well, within a second), while I can confirm that the Y axis seem to prefer to start from 0 when autoscaling. However, matthewnote includes 7.0.1.2 among the tested versions that still has the bug. Can others reproduce the non-updata part of the bug with the 7.0.x line of LO? See description in comment 46. (If one day only the autoscaling problem is left, it is probably better to open a new bug about that problem, which should be much more simple to describe.) Version: 7.0.1.2 (x64) Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded
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.
(In reply to Matthew Francis from comment #28) > OK, so I see what I did wrong before. The already fixed bug I mentioned in > comment 20 was for the chart in the "invoer" sheet, which works in 4.4 > already > > The issue I now see was meant is for the "roX0_9" chart, and is reproduced > as follows: > 1. Open attachment 114246 [details] > 2. Go to sheet "roX0_9" > 3. Go to sheet "invoer" > 4. Delete H19:L19 > 5. Go back to sheet "rox0_9" > > The diagram at A52:57 has not updated, but shows the updated values when > edited. > Note that the bug does not reproduce if step 2 is skipped. I still reproduce this problem. Arch Linux 64-bit Version: 7.1.0.0.alpha0+ Build ID: f08ddf3d3df0ef12fef36e96ffe6f5b9a7fda9e3 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 21 September 2020
More history about this "data value changes, charts not". Calc 4.1.3.2. Apache OpenOffice has the same problem since 2014 and still does (June 2020). The earliest/last known version of LibreOffice Calc that would open a broken Apache .ods and show the charts updating consistently (by comparison and file rescue attempts) was reported to be Calc 4.1.3.2. https://forum-test.openoffice.org/en/forum/viewtopic.php?t=71092&p=370292 Users try out OpenOffice then leave, going back to Excel due to this. Will attempt to find out if Apache Bug report exists. This topic is more than MAB or a "slight loss in productivity". The charts create well, present well, yet unless they update, it's unrealistic for a project that will be shared and a huge shock for a user who invests heavily before finding this out.
> > Users try out OpenOffice then leave, going back to Excel due to this. > Will attempt to find out if Apache Bug report exists. This topic is more > than MAB or a "slight loss in productivity". The charts create well, > present well, yet unless they update, it's unrealistic for a project that > will be shared and a huge shock for a user who invests heavily before > finding this out. As a user of LO I can confirm this and it is essential that this works well! In my work as a constructor, misinterpretations are regularly done, because the graph gives wrong information after updating the values. This can lead to serious construction errors with the consequences! I would really appreciate it if this important issue can be resolved.
I have changed the "Severity" field from "minor" to "normal". It is definitely more than just a minor nuisance, and those of us experiencing the bug may consider it major, but it seems that we are only a minority of users experiencing (or noticing?) the bug, so I kept at "normal". In any case, let's remember that LO is a project mostly performed by volunteers, and however a given bug is flagged, it is only fixed if somebody does fix it. With Bugzilla we have a flexible system for reporting bugs and providing examples. (If there is something similar for commercial systems like MS Office, I am not aware of it.) As I saw regarding some other bug that was very annoying to a user, a user has the following options after reporting a bug: 1. Fix it yourself. After all, the code is freely available, and volunteers fixing bugs are how most bugs are fixed. https://www.libreoffice.org/community/developers/ 2. Convince someone to fix it. Works best if you happen to know a programmer who is already doing work on LO. 3. Pay somebody to fix it. If you or your company have the money for it, there are professional developers that fix LO bugs, incorporating the fix into the mainline so everybody can benefit from the fix. https://www.libreoffice.org/get-help/professional-support/ 4. Wait. As for myself, I am not into the LO code, knows nobody personally who is, and do not have the money for hiring somebody to do the job. So I attempt to make good bug reports with easy-to-reproduce examples (when possible), and then settle for option 4. It can be annoying when the bug or enhancement request is important to me, but that is my option. And it does not stop me from being thankful that LO is there at all - in some cases with better features than MSO, in other cases with not quite as good features, but in all cases free to use if I want it.
(In reply to Lars Jødal from comment #53) > As for myself, I am not into the LO code, knows nobody personally who is, > and do not have the money for hiring somebody to do the job. So I attempt to > make good bug reports with easy-to-reproduce examples (when possible), and > then settle for option 4. Remember that you don't have to limit yourself to creating reports, you can also analyse the reports of others, which can be very valuable: https://wiki.documentfoundation.org/QA/GetInvolved#Quick_start_guide_for_beginners I'm not going to debate the severity, but we define even minor as making it "substantially harder to make high quality work or require users to not use some features": https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
(In reply to Lars Jødal from comment #47) > Importance: I agree that trustworthy updating of plots is important, > especially if you work with many plots. A few years ago, I used LO for my > Ph.D. project, and it was huge problem to me that plots very often did not > update - I did not know which plots I could trust, and there were a lot of > them, so a workaround of moving all plot a few pixels each was very > unattractive. (But yes, I kept using LO, and I am still a user.) > > Pinning it down: Like matthewnote writes, it is not an issue that is easy to > pin down. I have mostly experienced it with many plots, something many users > are not going to do. > > Status of the bug? I just tested matthewnote's sample file, attachment > 165696 [details], using LO 7.0.1.2 on Win10. Interestingly, the plot does > seem to update immediately (well, within a second), while I can confirm that > the Y axis seem to prefer to start from 0 when autoscaling. However, > matthewnote includes 7.0.1.2 among the tested versions that still has the > bug. Can others reproduce the non-updata part of the bug with the 7.0.x line > of LO? See description in comment 46. > > (If one day only the autoscaling problem is left, it is probably better to > open a new bug about that problem, which should be much more simple to > describe.) > > Version: 7.0.1.2 (x64) > Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 > CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: > win > Locale: da-DK (da_DK); UI: da-DK > Calc: threaded Thankyou Lars for your observations. This week I'm putting off returning to Cancer research (unpaid, as it often is) and investigating this Bug. I may have a clue after unzipping the files and inspecting Object folders. There is a difference and somewhere, Calc versions may decompress/infer objects differently when opening. When saving, there are new additional folders which I find in "working spreadsheets" (!) and find also a different META-INF/manifest.xml manifest:version. (version 1.3 rather than 1.2). No idea yet how a Calc version did that, yet willing to learn. Would you have a moment to open again my attachment http://bugs.documentfoundation.org/attachment.cgi?id=165696 check it's still working with you, save it with a new name using your Windows Build and send it to me by email? I've two Linux workstations here, no Windows. Are you still on precisely the same LO Calc Version and Build? It may be one of the few that gets this right. By the way, I did consider virus (really!) and had the sample file scanned by 15 different virus scanners. All well there. Hopefully yours Matthew
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?
(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
Additional note/reminder for others reading this thread. My sample file is only done on Ubuntu LO 6. I don't have a Windows workstation here. LibreOffice is chosen for the project because the medical data is coming in from all over the world, from some very remote regions. Isolated groups of up to 100 000 people is (in this subject) the most valuable and it's extremely accurate. They can be seriously ill and it gets reported precisely. However, for many, access to information technology is only for a few administrators, beyond the reach of nurses and clinical staff with near no budget for that. Pen and paper only. With LibreOffice, if they have access at home, the intention is to provide three levels of spreadsheet complexity/capability and they can see it for themselves. It's an ideal scenario for open source software - once I can share it.
Testing attachment 165696 [details] not working LO 6.4.6.2 I attempted a manual modification of my attachment .ods to cause Calc to generate ObjectReplacements folder and object binaries. The idea was to cause it to be the same as the unique unusual very large file here which always works (unbreakable so far and has the unique ObjectReplacements folder). 1. Unzipped 165696 .ods 2. Edited META-INF manifest.xml 3. Added line full-path for each and every Object (example 462) known also in the manifest.xml <manifest:file-entry manifest:full-path="ObjectReplacements/Object 462" manifest:media-type="application/x-openoffice-gdimetafile;windows_formatname="GDIMetaFile""/> 4. Added manually new empty folder ObjectReplacements (ready for Calc to insert binaries or due to Bug odd behaviour perhaps cause/Enable cache/Table redraw triggering). Don't know so try it out . . . . 5. Zipped everything up using zip -r ../test.ods mimetype * 6. Unzip again to check the full list and again the manifest. All OK there. 7. Run test.ods on LO7.0.1.2 on Fossa 20.04. Charts update (!). So a repair may have occurred. 8. However, saving a copy as "tested on LO7.ods", unzip it, the manual changes have been eliminated/deleted. The folder has gone and the manifest entry also. It will take a while to learn if the 165696 file is now unbreakable. Usually a few edits, copies, new sheets or copy a chart will break other charts. 9. Run test.ods (reconstructed file with manual mods) on LO7.0.1.2 on Bionic Beaver 18.04. Results as for steps 7 and 8. Charts now work. Manual modifications also eliminated after saving. Next I'll test VLB's file and test.ods on LO6.4.5.2. (I purge the repository ppa of LO7 to do that. Ubuntu 18.04 goes back to default companion package 6.x.x.x. Anyone know why one use of LO7.0.1.2 will create ObjectReplacements and another use will delete the folder? More later. . . .
After a purge of ppa LO7.0.1.2, Ubuntu BBeaver 18.04 offered LO6.3.5.2, so installed that. Results. Testing attachment 165696 [details] the chart fails to update (as before). Testing the test.ods (same as 165696 but with manually edited manifest.xml and manually added ObjectReplacements folder) chart fails to update. Saved the test.ods as a copy using LO6.3.5.2 then unzip to find out changes. The software run removed/cleaned the manual entries from manifest.xml and ignored/deleted the manually added ObjectReplacements folder. Provisional conclusion: 1. A User is unable to provoke the generation of ObjectReplacements. 2. Use of LO7.0.1.2 sometimes will cause the attachment file Chart to update and sometimes not. 3. The LO7.0.1.2 first upgrade/install on Ubuntu 18.04 caused a freak incident that repaired a very large file, only once (which uniquely has a software generated ObjectReplacements folder). It also broke a partly working very large file such that no Charts update; none at all (without generating the mystery ObjectReplacements folder either in that case). 4. Unfortunately, LO7.0.1.2 works only sporadically as a repair tool. more testing on VLB's file to be done.
VLB's file attachment 114246 [details] tested using method at comment #28 The file meta.xml shows generator as LibreOffice/4.4.1.2$Windows_x86 LibreOffice_project/45e2de17089c24a1fa810c8f975a7171ba4cd432 Tested on Calc 7.0.1.2 on Fossa 20.04. Chart fails to update. Tested on Calc 6.3.5.2 on Ubuntu Bionic Beaver 18.04. Chart fails to update. Unzipped the .ods. VLB's file does have an ObjectReplacements folder and manifest.xml entries showing full-path to that folder for each and every Object.
Created attachment 166115 [details] AppImage bundles can repair "broken" charts on any file? Windows test please. (In reply to Eike Rathke from comment #40) > This doesn't even seem to be a Calc problem, one can as well directly modify > the values in the chart's (Object 15) data range $roX0_9.$U$9:$U$18 (i.e. > set U13:U18 to 8 which is the same value as when deleting invoer.H19:L19, or > any other value fwiw) and the chart does not update. BUT, double clicking it > reveals the updated chart according to the values. Leaving the chart again > displays the old values. Also modifying the data ranges for data series > 'Column V' doesn't change that. Something seems to be broken with the chart > view representation (old replacement/preview view used?). Tested VLB's attachment sample here on two Linux PCs. File repair accomplished on Linux machines. 1. Download AppImage from Antonio's library of old versions: https://libreoffice.soluzioniopen.com/old/LibreOffice-5.3.6-x86_64.AppImage 2. Make the file executable. Run the AppImage on either Ubuntu 18.04 or 20.04. Tools>Options>Load/Save>General> switch off autorecovery saving, check ODF format set to 1.2 (Extended). 3. Open attachment 109539 [details] or attachment 114246 [details] or my sample attachment 165696 [details]. 4. All Charts update with any user operation (here). 5. Save the resulting file to a new file name (necessary before step 6). 6. Files now load, charts now update (all samples) on Installed Calc versions LO6.3.5.2 on Ubuntu 18.04. LO7.0.1.2 on Ubuntu 20.04. Repaired files now load, charts update on AppImage version LO5.3.6.1 and AppImage version LO6.5.3.2 and AppImage version (fresh) LO7.0.1.2. 7. For Users reading this Bug, the AppImage project produces "boxed" full LibreOffice versions without installing anything. This is similar to .sfs "boxed" full versions available to Linux Puppy users. (I don't know if Windows has or will have an equivalent). So, for Windows OS users, you'll need to find a friend or a Linux partition to use AppImages as repair tool. 8. For Developers. a. Antonio's AppImage 4.1.0.4 failed to start on either Linux 18.04 or 20.04. b. AppImage 6.3.5.2 ran on both Linux yet failed to cause chart updates. c. AppImage 6.3.5.2 opens all, charts updates if they've been save at least once using AppImage 5.3.6.1. d. AppImage 5.3.6.1 (the successful Repair Tool) failed to run on Fossa 20.04 at the first try, yet double-clicking it later and again later (the third occasion), the application launched (very strange!). It seems only Antonio's 7.0.1.2 "fresh" has a Fossa Ubuntu 20.04 flavour. Not sure why the AppImage 5.3.6.1 had difficulty attracting software interrupt attention. Another clue? Would ladies, gentlemen please test the "seems repaired" VLB sample on Windows and report result? Attached with this message. Method is at comment 28. [By the way, the Repair Method using AppImage works also for my upload and this morning I tried it out on the very large (102MB) Diabetes file study here with 42 charts. Half of the charts were "broken" and now . . . . . . all are working! I'm very happy this morning).
Pardon. To clarify. The VLB file that seems "repaired" is attachment 166115 [details]. It now works here (chart updates) on fully installed Linux LibreOffice versions. Requesting test on a Windows system and other Linux versions. For VLB. For Lars. If you have a new current project with "broken" charts using a more recent version of Calc I offer to attempt to repair them for you. Just send them to me by email or any google drive you can give access. This computer handles files up to 102MB without difficulty (about 9GB in RAM). Well, just an offer if it helps you out.
> Would ladies, gentlemen please test the "seems repaired" VLB sample on > Windows and report result? Attached with this message. Method is at > comment 28. > I have test attachment 166115 [details] in wi10 LO 7.0.1.1 (x64). All graphs work, except for the graph on the 1st sheet "invoer". This chart will not be updated. I have download the file AppImage. I also tried to use the file in Ubuntu, but my knowledge in Ubuntu is limited. How do I make the file executable?
(In reply to VLB from comment #64) > > Would ladies, gentlemen please test the "seems repaired" VLB sample on > > Windows and report result? Attached with this message. Method is at > > comment 28. > > > > I have test attachment 166115 [details] in wi10 LO 7.0.1.1 (x64). > > All graphs work, except for the graph on the 1st sheet "invoer". This chart > will not be updated. > > I have download the file AppImage. I also tried to use the file in Ubuntu, > but my knowledge in Ubuntu is limited. > How do I make the file executable? With Ubuntu here, mouse- cursor over the file symbol or name. Click mouse (right button), "Properties" "permissions". At lowest box of the dialogue "Make file executable". Close dialogue box. Doubleclick the file. Works for you? With all the project here, there's a user impression that all or any LibreOffice full install may start correctly then later charts stop updating (sometimes whole sheets of charts). Thank you for your test 7.0.1.1 ( an installed version). I will be using only AppImage for a few days or weeks with several files to learn if it's more "stable", temporary fix or a permanent repair (only for continuous AppImage use in future). For a few more days now I'm working through the .xml (including content.xml) files of your LiggerV26 to find if there's an obvious difference. I've found some differences already. For a developer who looks at this, VLB's file has the chart (not updating) Object number 15. AppImage keeps the same object numbers; cleans up (removes) some ObjectReplacements; sets additional loext values in content.xml etcetera. I'll report later if something seems pertinent about that.
(In reply to VLB from comment #64) > > I have test attachment 166115 [details] in wi10 LO 7.0.1.1 (x64). > > All graphs work, except for the graph on the 1st sheet "invoer". This chart > will not be updated. Good morning. Checking again here, all charts function with AppImage. With 7.0.1.1 on Windows, which of the four charts is the only one to fail to update on "invoer"? The chart covering cell A58, M58, M66 or M74?
(In reply to matthewnote from comment #66) > (In reply to VLB from comment #64) > > > > I have test attachment 166115 [details] in wi10 LO 7.0.1.1 (x64). > > > > All graphs work, except for the graph on the 1st sheet "invoer". This chart > > will not be updated. > > Good morning. Checking again here, all charts function with AppImage. With > 7.0.1.1 on Windows, which of the four charts is the only one to fail to > update on "invoer"? The chart covering cell A58, M58, M66 or M74? The test was in LO 7.0.1.2 (x64) and not 7.0.1.1 I tested again this morning and amazingly all graphs are now being updated (including the graphs on the 1st sheet). Yesterday it was all 4 graphs on the 1st page that were not updated.
Thankyou VLB For developers. Overall impression. 1. Any installed/integrated version of LibreOffice Calc on Windows or Linux can cause Charts to fail to update, begin again to update, then it's a different chart that fails, then it is many. The situation changes with every load/save or edit/save. VLB's attachment is rare because the fault stays the same. (This was tested also on Xenial Puppy Linux using either Apache or LibreOffice: same problem). 2. An appropriate AppImage executable (that matches the original file that stimulates errors in the installed verions) will immediately work with all charts updating on all sheets. This is the effect I have tested here on Ubuntu 20.04 , Ubuntu 18.04. It also works/charts update using a Xenial Puppy Linux LibreOffice 6 .sfs standalone. The User can make progress with his/her project. 3. Saving a file using AppImage can repair it. That saved file can work immediately in installed LibreOffice versions on Linux or Windows (or maybe not). It takes a lot more testing to learn if that will break it again later. 4. AppImage treatment can a. delete some ObjectReplacement files (about half disappear, if any). b. insert new lines into Object\ content.xml, such as loext:min-decimal-places="0" loext:try-staggering-first="true" oext:try-staggering-first="false" Please guide me what work to do about .xml compare that might help you. I use https://prettydiff.com.
*** Bug 136254 has been marked as a duplicate of this bug. ***
(In reply to Matthew Francis from comment #28) > OK, so I see what I did wrong before. The already fixed bug I mentioned in > comment 20 was for the chart in the "invoer" sheet, which works in 4.4 > already > > The issue I now see was meant is for the "roX0_9" chart, and is reproduced > as follows: > 1. Open attachment 114246 [details] > 2. Go to sheet "roX0_9" > 3. Go to sheet "invoer" > 4. Delete H19:L19 > 5. Go back to sheet "rox0_9" > > The diagram at A52:57 has not updated, but shows the updated values when > edited. > Note that the bug does not reproduce if step 2 is skipped. Just tested with LO 7.0.2.2 on Win10. (Macros disabled.) The bug is still present: After deletion of the cells in step 4, the chart in sheet "roX0_9" us unchanged. Double-clicking on the chart makes the change come through (less points in the plot, lines reflecting the points that are now present). When the chart misses focus, e.g. clicking outside the chart, it reverts back. User profile reset: Yes, just before the test. OpenGL: Bug is present both with and without OpenGL. Conclusion: The bug is still present in LO 7.0.2.2, it is still expressed on Windows (not only Linux), and the above example is file of reasonable size (2.4 MB) and easy-to-reproduce instructions. Further considerations: Comment #19 indicates a commit that introduced at least some variant of the bug, although comment #20 indicates that a later commit appeared to fix the bug. Given that we still struggle with these problems, perhaps the commit solved part of the problem. Definitely, the problems is not fully gone, as demonstrated by a number of comments, this one included. Version: 7.0.2.2 (x64) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: da-DK (da_DK); UI: da-DK Calc: threaded
I was able to reproduce as described in comment 70. I've repeated the description below and inserted some notes as to exactly what I did: 1. Open attachment 114246 [details] {note -- I just clicked on the attachment number and downloaded the file} {note -- when I saw the pop-up about macros being enabled, I disabled them.} > 2. Go to sheet "roX0_9" > 3. Go to sheet "invoer" > 4. Delete H19:L19 {note -- here I got an error because I was in read-only mode, so I went into edit mode.} > 5. Go back to sheet "rox0_9" {At this point, I saw the bug in all its glory, as described in comment 70.} Here's all the information that might be relevant about my environment: Hardware: Dell Inspiron 620 with 8GB memory, 64-bit OS: Win7 home premium, SP 1 LibreOffice information: Version: 7.0.1.2 (x64) Build ID: 7cbcfc562f6eb6708b5ff7d7397325de9e764452 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
I have just reproduced the bug a second time as described in my previous comment #71. I have another computer with Ubuntu installed. If I have time, I will try to reproduce it there.
*** Bug 136160 has been marked as a duplicate of this bug. ***
Was able to duplicate it a third time under Lubuntu (Ubuntu with a different desktop, whose name I forget). It is on an Ultrabook with a Core i3 processor Ubuntu is 20.04
Here is a small update, thanks to the efforts of Matthew! I had my 3 private sheets saved by Matthew in Appimage and tested them in LO 7.0.1.2 and worked well, with all graphs processed properly. Then I opened several files (which had been processed with Appimage and then I came to an important signal that the graphs were no longer processed properly. An important thing had emerged which may have to do with memory and that the graphs are therefore no longer displayed properly. It would be greatly appreciated if this new finding clarifies the problem definition and if a solution can be sought.
The issue may have been brought closer to a solution in comment 75 by the observations. If more information is needed for the solution, we will gladly inform you. There is also an additional observation and is the following: 1) Save the files with graphics in a * .xlsx file. 2) In this file type the graphs are displayed correctly after data is changed, compared to * .ods file. 3) The disadvantage of this is that the files are 3 times as large. 4) Certain sheets are not yet properly converted to * .xslx, so it cannot be used for all sheets.
(In reply to Buovjaga from comment #49) > (In reply to Matthew Francis from comment #28) > > OK, so I see what I did wrong before. The already fixed bug I mentioned in > > comment 20 was for the chart in the "invoer" sheet, which works in 4.4 > > already > > > > The issue I now see was meant is for the "roX0_9" chart, and is reproduced > > as follows: > > 1. Open attachment 114246 [details] > > 2. Go to sheet "roX0_9" > > 3. Go to sheet "invoer" > > 4. Delete H19:L19 > > 5. Go back to sheet "rox0_9" > > > > The diagram at A52:57 has not updated, but shows the updated values when > > edited. > > Note that the bug does not reproduce if step 2 is skipped. > > I still reproduce this problem. > > Arch Linux 64-bit > Version: 7.1.0.0.alpha0+ > Build ID: f08ddf3d3df0ef12fef36e96ffe6f5b9a7fda9e3 > CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5 > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > Calc: threaded > Built on 21 September 2020 USER WORKAROUND - QUIT ODF FORMAT - WORK IN XLSX UNTIL BUG FIXED Please add your vast experience, overview and opinion for Users. We (LibreOffice and Apache communities) have a fundamental problem. Education is precisely where LibreOffice can be the best: yet students (including Lars, up to PhD level) need to show a graph that shows the data. I can (am able) to learn Python, having learnt Machine Code (bit manipulation), Assembler (extreme efficiency), Fortran 4 (precise compiler), Coral 66, SciLabs 2012 (Equivalent MatLab) yet my experience is with Realtime processing (Raytheon) and no time at all for a new adventure with ODF. Yet I am investigating six files here with differences in .xml. The workaround suggested below is completely ignorant of the multiple limitations of working with LibreOffice in xlsx format - yet it seems to work. USER POTENTIAL WORKAROUND while waiting for Bug Fix with more symptoms for developer info (Step 7-12). Charts not updating can be made to update by 1. Click and Drag the chart area a few pixels. If there are many charts depending on one Series update, User must check all charts on all sheets. Charts not updating sometimes can be made to update by 2. File>Save Restart LibreOffice File>Recent Documents>Open This rarely works, can take a lot of time and every number change requires reload. 3. Zoom in/zoom out the sheet view has be known to cause chart update (but very rare). 4. Using AppImage 5.3.6.1 is tested to open faulty files and show charts updating immediately. However, it’s usual that the new *.ods file will fail to update later after more edits. AppImage 5.3.6.1 as a regular rescue tool every hour or every day is only available for Linux. The new *.ods file can be shared. Yet opening several files (rescued with AppImage) at the same time will cause different chart failures. A method is needed for Windows OS. NEW FINDING. Charts not updating will always be made to update by saving in xlsx format. 5. The User has a new decision to make. Using LibreOffice every day in xlsx format depends on Charts with Data Series formats that transfer well (triangles, squares, diamonds), simple colours. The User learns to avoid Functions that are special to LibreOffice yet impossible to translate for Excel. This is difficult (for advanced users). This method is described below for Users to test (a clue for developers also). 6. Users don’t know if this Bug Report will ever be assigned. If you are a Student, Teacher or using the spreadsheet to mostly calculate (with simple graphics) it can be an option to change format now. If the Bug receives attention in future, then it will be possible to save again in ODF format and elaborate/clean the cell functions from that new LO version. Of course, for engineers, scientists, students and teachers it is basic that the plot shows the same numbers as the cell. The Bug causes much doubt, mistrust and stress. An occasional review of the xlsx file progress is, perhaps, less painful. Testing the file suitability with this method. 7. IF the spreadsheet file is mostly technical or mathematical, this Workaround may be suitable. If the spreadsheet has scatter charts with the series formatted in special colours and symbols for presentation, it will need some work or can be done later (after BugFix) with ODF advantages. If the file uses Indirect Adressing or Functions the new file need be checked thoroughly. 8. The Workaround (for a file with ordinary charts) is to change to Excel 2007-365 XLSX format until the ODF Bug is fixed. 9. When the charts fail to update or when testing to do it deliberately, File>Save As> (bottom right filetype) select xlsx Excel 2007-365. A new name is useful like "abcde XLSX.xlsx" to make it obvious when using a File Manager. LibreOffice will ask are you sure? A warning will appear that some details or calculations may be lost. User can check that later. 10. Click to confirm save Excel xlsx 2007-365. The charts on the sheet being viewed at this time will all update correctly while you watch. Magic! Note: At the top of the LibreOffice calc (the black title bar) the file name has changed to abcde.xlsx. (LibreOffice is still running in it's own display system and other graphics may fail to update). LibreOffice is showing you a display equivalent of the xlsx, not yet the true xlsx effect. 11. Save/Close all other .ods files. Close LibreOffice. Restart LibreOffice. 12. File>Open only the xlsx file. All Charts are now updating. This conversion/rescue can be done for more *.ods files. Restart LibreOffice for each file (only one conversion at a time). Note: It is also now possible to start LibreOffice and open all the new xlsx files at the same time. All Charts update everywhere on all sheets of all files (according to the tests done on two computers here. Please comment if you find problems in future). 13. Inspect the new xlsx presentation for symbol, colour changes, Indirect Address failures (if the ods file uses it), Chart scales etc. Minor differences are that xlsx shows # for calculations that cannot be completed (source data off or inhibited) where the ODF (*.ods) showed #VALUE! 14. It is possible to continue the project for the User always in Excel format. LibreOffice does this very well! When the Bug is fixed, then Save as>abcde.ods> (confirm) ODF version is new choice. 15. Unfortunately, editing the files in future will cause new Chart failures (cause unknown, not yet identified). This Bug 86321 is still possible when editing. However, save/reopen in xlsx seems always to work and is quick (on Windows also). Please test for yourself. DISADVANTAGES. 16. When the User inspects the new xlsx charts, some lines are changed from dashed to continuous. If the user changes those line again, the Chart will fail to update. File>Save File>Open xlsx needed again. 17. If the User has created the ODF project with many different formats for scatter plot Data Series, those colours and symbols are changed to simple blue squares. 18. The xlsx file can be nearly twice the size in MBytes. For example 9.9 MB in ODF became 21 MB in xlsx. Yet a different very large file (101.7MB) was precisely the same size ODF/xlsx. LIMITATIONS OF THE USER WROKAROUND 19. Users estimate that an xlsx file can be shared with colleagues using Excel. It is necessary, before sending a file to check how it presents on a working Windows/Office system. It will be very different again! The workaround concerns using xlsx format to develope the user project until this Bug is Fixed. 20. attachment 114246 [details] is an example of a file that is suitable for xlsx conversion and development. attachment 165696 [details] is an example of a file that is unsuitable (due to extensive use of LibreOffice tools that are excellent yet not translated into xlsx formats). [Example: With my four year project, it is too late to work every day now in xlsx format (even if LibreOffice does it very well). My designs were all based on analysis by x,y scatter and ODF functions]. Summary 21. File save/close/open again sometimes works with *.ods. Mostly it does not solve the problem. Testing here save/open of *.xlsx always repairs chart update.! This is the unique advantage. Workaround tested on: Version: 7.0.1.2 Build ID: 00(Build:2) CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.0.1-0ubuntu1_oibaf~f Calc: threaded Version: 7.1.0.0.alpha0+ Build ID: 8eff280bc08ec3d7b2312ae4ee48df4d7328b7de CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-10-07_08:11:21 Calc: threaded Version: 6.3.5.2 Build ID: 1:6.3.5~rc2-0ubuntu0.18.04.1~lo1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded Versie: 6.4.6.2 (Dutch language) Build ID: 1:6.4.6-0ubuntu0.20.04.1 CPU-threads: 2; Besturingssysteem: Linux 5.4; UI-render: standaard; VCL: gtk3; Locale: nl-NL (nl_NL.UTF-8); UI-taal: nl-NL Calc: threaded Version: 7.0.2.2 (x64) Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 16; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win Locale: nl-NL (nl_NL); GI: nl-NL Calc: threaded WORKAROUND FAILURE The last Chart on VLB's attachment last sheet in xlsx format - the data triangles disappear - only the line is seen). Full details Xenial Puppy Linux with LibreOffice 6.1.0.3 in *sfs executable form. Version: 6.1.0.3 Build ID: efb621ed25068d70781dc026f7e9c5187a4decd1 CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded This failure may be most pertinent for SFS reading this comment. Experience with Lubuntu (KDE) here is that there are multiple crashes running LibreOffice which are resolved since Ubuntu moved to Gnome. A Lubuntu PC here was crashing ten times per day (set LibreOffice autorecovery on!). When wiped and replaced with full Ubuntu Bionic Beaver 18.04 - several months with no crashes at all. In fact, I now switch off LibreOffice autorecovery when I use 6.3.5.2 or 7.0.1.2. The Linux is rock solid.
Created attachment 166553 [details] Screenshot; Comparing unzipped odf content.xml between AppImage5 and LO4 More about the Bug - using QXmlEdit to compare the ODF content.xml after saves. Calc 4. The screenshot (right hand side in red) shows that the Calc 4 used to save attachment 109539 [details] writes content.xml using draw:object <table:table-row><table:table-cell><draw:frame><draw:object> Attributes: draw:notify-on-update-of-ranges=roX09 . . . . . . Calc 5.1.6.2 all versions up to 5.4.7 changes the strategy. The screenshot (left hand side in green) shows that Calc 5 opens the version 4 file, reads that Object 17, updates the Chart correctly when data series cell values change. Saving the file, Calc 5 deletes the original Attribute (gone), then adds a completely new element in content.xml one level up at draw:frame <table:table-row><table:table-cell><draw:frame><loext:p> Attributes: draw:notify-on-update-of-ranges=roX09 . . . . . . [Note: Calc 5 then adds another completely new attribute into Object 17/content.xml <style:style><style:chart:properties>Attributes: loext:try-staggering-first="true" ] Calc 6 and 7. These versions remove the Calc 5 strategy and go back to the same xml organisation as for version 4. This is deliberate or a regression? Further evidence. Calc 5 is therefore very useful for repairing a file or User work. Every time the file is saved and reopened, it's repaired. However, Calc 5 still has this Bug. Example of the User dilemma when creating a project: Step 1. Open attachment 109539 [details] using Calc 5. Click to view sheet roX0_9 Step 2. Click to view sheet invoer Step 3. Delete cell contents of invoer H19:L19. Result, all charts update on all sheets (including roX0_9) Step 4. Leftclick to view sheet vb_610a Step 5. Rightclick "Insert Sheet", "After current sheet" "Name" any. OK Step 6. View again invoer and replace H19:L19 (values 5 4 3 3 3) Result, charts on invoer are showing triangle points with eight x-axis values, some are three values. Three Charts are showing both old and new values (both eight points and three points are superposed). Step 7. View again vb_610a. Result, none of the charts on that sheet update. Step 8. On vb_610a click and drag a chart Area a few pixels. Chart updates. Step 9. View sheet vb_610b, charts are correct. Step 10. View sheet eg, charts are correct, however the top chart frame is squashed, causing the triangle symbols to be short. Step 11. Click and drag top chart area and move it a few pixels. Draw is good. Step 12. View sheet loX0_9, charts are already updated correctly. Step 13. View sheet roX0_9, charts are not updated. Clickdrag chart areas. Result, charts now update. Step 14. File>Save then File>Close then File>Open Result, all charts on all sheets are updated (in correct draw state). Step 15. Change any value of the Data Series for any chart Result, all charts on all sheets update correctly. LibreOffice Calc 4,5,6,7 all seem to have this Bug. Only Calc 5 will save the User work and reopen it with all Charts working. However, using Calc 5 to edit or add sheets causes new failures to update and those frozen Charts can be anywhere on any sheet. I've tested with seven LibreOffice versions and the adoption of the LO4 save content.xml structure came back with precisely LO 6.0.0. Therefore, File>Save File>Close then File>Open repair is no longer available for users who have upgraded. I've seen LO6.3.5.2 refresh a sheet once, but usually the charts on other sheets are failing to update. I hope the xml compare information is useful. Not sure if I can do more about this. For my project, I may remove Calc 6.3.5.2 and install 5.4.7. It's risky because I see a lot of bugs have been fixed, including problems with Indirect Addressing (that my work uses as a basis for it's design). Well, I'll contribute more if I can figure out how the summary in RAM of the sheet/chart situation is corrupted. Just a reminder: Once and only once, upgrading from Calc 6.3.5.2 to Calc 7 and opening the "worst" file first; it repaired all Charts and generated Object Replacements for all and the file is still working. Removing Calc 7 and reinstalling 6.3.5.2 then doing the upgrade process again did not repair any file. The second "installation 7.0" skipped some procedures of dependencies in Ubuntu 18.04, finding them already new, but I don't have a record of precisely which ones. It will be difficult to examine that particular ODF file because it is 102MB compressed already. Not many xml editors or compare tools can cope with the unzipped content.
Created attachment 166554 [details] Compare LO5 modification of Object/content.xml since removed; regression? Additional xml compare report for Object/content.xml as described previous comment. LibreOffice Calc 5 adds a new line for each and every Object "try-staggering-first".
To clarify. There are two bugs implied. First Bug. During work on a project, Calc versions 4,5,6,7 use a "register" (of some sort) that follows the situation of which Objects are on which Sheet. That has redraw functions (of which three are changes in Object position, changes in scales used and changes in Data Series). The start situation is loaded from /Object*/content.xml and the main ODF content.xml. When the user inserts a new sheet or copies an existing sheet, the "register" becomes out of date or scrambled/corrupted). When the user views other sheets, various chart Objects respond to position redraw criteria but not the scale nor Data Series. Some charts show x-axis now stretched to accomodate two different sets of Data Series superposed although apparently only one y-axis series is plotted. The x-axis stretch is very variable and implies the redraw is attempting to mix data that is actually for a different Object on a different Sheet. [Note: the chart Data Series readout for the user is unchanged, the original intended]. If the user copies a chart (makes a twin), the "register" functions, puts the new Object into memory appropriately and that twin does update. Second Bug. When the user saves the file, Calc 4,6,7 save a faulty "register". On re-opening the file any or many charts fail to update (not always true and not always the same charts). Saving with all Calc versions 5.*.*.* does something more thorough before writing. The register is "revised" or "cleaned up" in some way before writing. Some charts visible to the user are still frozen yet closing/re-opening the file finds the new content.xml and object/content.xml compatible, correct and all charts working. With further Calc 5 user activity, the first Bug will, again, cause new freezes of charts. Saving with format .xlsx causes a similar "revise" or "clean up" as Calc 5 with an additional final "redraw" of objects that had changes during the user session. Therefore, unlike Calc 5, the user sees the presentations jump to the correct data values. First and second Bug together. If the user opens two or three .ods at the same time and does edits, the "register" (apparently, it seems) becomes corrupted across any or many sheets on any of the open files. Then it's necessary to File_Save with Calc 5 (then reopen each) or File_Save as .xlsx for all open files.
(In reply to matthewnote from comment #80) > To clarify. There are two bugs implied. Then it would be nice to create a separate report for the other bug, especially in this case where we have reached 80 comments on this original one.
> Second Bug. When the user saves the file, Calc 4,6,7 save a faulty > "register". On re-opening the file any or many charts fail to update (not > always true and not always the same charts). See new report bug 137735.
(In reply to matthewnote from comment #79) > Created attachment 166554 [details] > Compare LO5 modification of Object/content.xml since removed; regression? > > Additional xml compare report for Object/content.xml as described previous > comment. LibreOffice Calc 5 adds a new line for each and every Object > "try-staggering-first". So LO 5.x worked ok, which could mean that the original bug was solved but then some new bug caused a regression with the same or similar behaviour. Likely some optimization of diagram updating that "optimized" recalculation too much. I have performed the test from comment #28 with a few 5.x versions, and can confirm that diagram update DOES work for that file. The regression is present by 6.0.0.0.beta1, while 6.0.0.0.alpha1 does update the diagram. First question: Does the test from comment #28 test for "First bug" from comment #80, or for "Second bug" (now split out as bug 137735)? Second question: What will constitute a simple test example for the other bug (whether "first" or "second") not tested for by the procedure in comment #28? (This thread is becoming quite scary just by its size. While details can reveal new findings, I think that at the present stage we are more in need of simple test cases with simple descriptions.)
> First question: Does the test from comment #28 test for "First bug" from > comment #80, or for "Second bug" (now split out as bug 137735)? This test comment #28 is for the 2nd bug 137735. > Second question: What will constitute a simple test example for the other > bug (whether "first" or "second") not tested for by the procedure in comment > #28? If the 2e bug 137735 is solved, the problem is that when opening multiple sheets with multiple graphs, randomly determined graphs no longer work. This is bug 86321. The thought is that this is due to caching or something similar.
> (This thread is becoming quite scary just by its size. While details can > reveal new findings, I think that at the present stage we are more in need > of simple test cases with simple descriptions.) For this bug 86321 it can be reproduced with the following steps: 1) Installeer LO 5.4.7 2) Open attachment 114246 [details] 3) Save the file in other/different name 5 sheets or more 4) Open all files 5) Delete cell H19:L19 in all files and save all files 6) Enter the following value in all cell ïnvoer" H19:L19 in all files/sheets, number "8" 7) Look at the different graphs on the following sheets "invoer A52:P57" + "vb_610a A52:p57" + "vb_610b A52:p57" + "eg A52:p57" + "loX0_9 A52:p57" + "rox0_9 A52:p57" 8) Not all graphs have been updated.
(In reply to Lars Jødal from comment #83) > (In reply to matthewnote from comment #79) > This thread is becoming quite scary just by its size. While details can > reveal new findings, I think that at the present stage we are more in need > of simple test cases with simple descriptions.) Bug 137735 proposes the precise method at comment 78 so that readers know how to corrupt the loading of any file, even if it works once before and how to restore the file. The Bug also details all results for all calc 5 versions. It also gives a user workaround in Windows versions. Calc 5.4.7.2 still has this bug here (due to many types of edits) but Save-Close-Open restores it every time. I try to brief. Testing or (we hope) beta testing a bugfix can be done by e-mail - no need to post here. However, until someone skilled volunteers to assign it to themselves (with a contact address) I think the only option is to place all the facts to encourage him or her to start/attempt.
bug 86321 does update by LO 4.2.8.2, but no longer with LO 4.3.0.1.
(In reply to Joel Madero from comment #15) > This is not a critical bug - I'm not sure who marked it as such. > > Marking as: > Minor - there is a workaround (see last comment). It can slow down > professional quality work but will not prevent it. Critical is reserved for > major crashes and serious data loss - this is neither. > > I'll leave as highest and leave it on MAB list. > > Please do not revert my changes. > > > What would be nice is for those seeing this issue to test older releases to > see if it's a regression. > http://downloadarchive.documentfoundation.org/libreoffice/old/ > https://bestfreehdporn.pro/category/anal-porn-paysites/ > > Best thing to do is to test 3.3 - if it's present in 3.3 then it's not a > regression (please leave a comment). If it isn't present in 3.3, then start > testing every release (3.4, 3.5, 3.6, 4.0, etc...) to try to narrow where > the bug came in. fixed?
I can reproduce the bug on Libreoffice of below version. Version: 7.0.5.2 (x64) Build ID: 64390860c6cd0aca4beafafcfd84613dd9dfb63a CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL (In reply to Blair Mault from comment #88) > (In reply to Joel Madero from comment #15) > > This is not a critical bug - I'm not sure who marked it as such. > > > > Marking as: > > Minor - there is a workaround (see last comment). It can slow down > > professional quality work but will not prevent it. Critical is reserved for > > major crashes and serious data loss - this is neither. > > > > I'll leave as highest and leave it on MAB list. > > > > Please do not revert my changes. > > > > > > What would be nice is for those seeing this issue to test older releases to > > see if it's a regression. > > http://downloadarchive.documentfoundation.org/libreoffice/old/ > > https://bestfreehdporn.pro/category/anal-porn-paysites/ > > > > Best thing to do is to test 3.3 - if it's present in 3.3 then it's not a > > regression (please leave a comment). If it isn't present in 3.3, then start > > testing every release (3.4, 3.5, 3.6, 4.0, etc...) to try to narrow where > > the bug came in. > > fixed?
*** Bug 141455 has been marked as a duplicate of this bug. ***
I have found a solution to this problem: Go to Tools->Options->LibreOffice→Advanced→Open Expert Configuration→ Search for ‘cache’→ Change org.openoffice.Office.Common→Cache→Drawing Engine (OLE_Objects) to e.g. 40 (default value 20). This value should be greater than your maximum number of charts in any spreadsheet that you use. A lower value causes some charts not to be updated when spreadsheet data is updated. It's a cache issue. Verified with: Version: 7.1.2.2 / LibreOffice Community Build ID: 10(Build:2) OS: Linux 5.8; UI render: default; VCL: gtk3 Ubuntu package version: 1:7.1.2~rc2-0ubuntu0.20.04.1~lo3 Calc: threaded
(In reply to Dimitris Kallipolitis from comment #91) > I have found a solution to this problem: > Go to Tools->Options->LibreOffice→Advanced→Open Expert Configuration→ Search > for ‘cache’→ Change org.openoffice.Office.Common→Cache→Drawing Engine > (OLE_Objects) to e.g. 40 (default value 20). This value should be greater > than your maximum number of charts in any spreadsheet that you use. A lower > value causes some charts not to be updated when spreadsheet data is updated. > It's a cache issue. Sounds like information that may be very helpful: a) As a way to circumvent the issue for the individual aware that this bug exists. b) For narrowing down the bug in the code. It does not stop this from being a bug of importance (IMHO), and I am among those who still hope it will be fixed one day and who will be thankful when it happens.
(In reply to Dimitris Kallipolitis from comment #91) > I have found a solution to this problem: > Go to Tools->Options->LibreOffice→Advanced→Open Expert Configuration→ Search > for ‘cache’→ Change org.openoffice.Office.Common→Cache→Drawing Engine > (OLE_Objects) to e.g. 40 (default value 20). This value should be greater > than your maximum number of charts in any spreadsheet that you use. A lower > value causes some charts not to be updated when spreadsheet data is updated. > It's a cache issue. > > Verified with: > Version: 7.1.2.2 / LibreOffice Community > Build ID: 10(Build:2) > OS: Linux 5.8; UI render: default; VCL: gtk3 > Ubuntu package version: 1:7.1.2~rc2-0ubuntu0.20.04.1~lo3 > Calc: threaded Thanks for the feedback on the issue! I have adjusted the value as indicated to a value of 90 (in connection with a sheet with 88 graphs) and tested it. I can conclude that this solves the problem for 1 sheet. Only I also have more of these shets open with miscellaneous adjustments (so maybe more than 4 * 88 graphs) and then notice that they are no longer updated. Can this value be increased indefinitely, without causing problems elsewhere? It would also be great if this problem could be solved in the source code, as already indicated in comment 92. Version: 7.1.2.2 (x64) / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL
I've just bisected this again. Regression introduced by author Armin Le Grand <alg@apache.org> 2014-02-18 21:18:13 +0000 committer Caolán McNamara <caolanm@redhat.com> 2014-02-19 20:29:12 +0000 commit db1d2af02861b49e4f53d726d59cd71c20cee9b1 (patch) tree a4edfc1235314f5e3d03c45a52863a052ad19286 parent 2237604b6b1d08439ac37f096a787c449a046b5f (diff) Resolves: #i123539# some optimizations for 3D chart... Bisected with: bibisect-43max I might have a solution for this...
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi, My patch in comment 95 fixes the steps in comment 28. For other issues, please, fill a new report. Closing as RESOLVED FIXED
The issue is easily reproduced with attachment 111198 [details] from bug 87622. My patch also fixed the problem in that file
(In reply to Commit Notification from comment #95) > Xisco Fauli committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b > > tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." > > It will be available in 7.2.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. Thank you very much for resolving the issue! Is it possible that it will also be pushed to LO version 7.1.3?
(In reply to VLB from comment #98) > (In reply to Commit Notification from comment #95) > > Xisco Fauli committed a patch related to this issue. > > It has been pushed to "master": > > > > https://git.libreoffice.org/core/commit/ > > eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b > > > > tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." > > > > It will be available in 7.2.0. > > > > The patch should be included in the daily builds available at > > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > > information about daily builds can be found at: > > https://wiki.documentfoundation.org/Testing_Daily_Builds > > > > Affected users are encouraged to test the fix and report feedback. > > Thank you very much for resolving the issue! > Is it possible that it will also be pushed to LO version 7.1.3? yep, https://gerrit.libreoffice.org/c/core/+/114277
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/3fe117cb0f319fbb84073d75ad5e2d676b587866 tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." It will be available in 7.1.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/99679f4dbfae6eb51a9a76b1cebd87e3d38b0c9c tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." It will be available in 7.0.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Xisco Faulí from comment #99) > (In reply to VLB from comment #98) > > (In reply to Commit Notification from comment #95) > > > Xisco Fauli committed a patch related to this issue. > > > It has been pushed to "master": > > > > > > https://git.libreoffice.org/core/commit/ > > > eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b > > > > > > tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." > > > > > > It will be available in 7.2.0. > > > > > > The patch should be included in the daily builds available at > > > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > > > information about daily builds can be found at: > > > https://wiki.documentfoundation.org/Testing_Daily_Builds > > > > > > Affected users are encouraged to test the fix and report feedback. > > > > Thank you very much for resolving the issue! > > Is it possible that it will also be pushed to LO version 7.1.3? > > yep, https://gerrit.libreoffice.org/c/core/+/114277 (In reply to Commit Notification from comment #95) > Xisco Fauli committed a patch related to this issue. > It has been pushed to "master": > > https://git.libreoffice.org/core/commit/ > eec03e848cb6874ce6d64dc0b8f45dbaf52e6c2b > > tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." > > It will be available in 7.2.0. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. I have test in 7.2.0 and it fix for 1 sheet with 88 graphs! Thanks. I created a new issue when opening multiple sheets at the same time, see issue 141799 Here F9 must be used to update the graphs.
HI VLB, thanks for checking. Let's close it as VERIFIED
Thanks for patching this long-standing issue. I have also tested with 7.2.0, and now sets status to "VERIFIED FIXED".
(In reply to Xisco Faulí from comment #96) > Hi, > My patch in comment 95 fixes the steps in comment 28. For other issues, > please, fill a new report. Closing as RESOLVED FIXED It is also possible to look at bug 141799 as it is very related to this fixed bug.
Hi all. Thankyou very much Dimitris and Xisco, all at QA and VLB for tenacity! Tested another attachment file already here on this Bug Report. 1. Opened attachment 165696 [details] using 7.1.4.0.0+ on Ubuntu 18.0.4.2 2. Sheet "TheSWITCHexpanded" shows. Test is done at L259 with chart at C283. 3. Change L259 from value 17 to value 25. Enter. 4. Chart X293 clears all plots (correct). Chart C283 does not update (incorrect). 5. Expected result; chart C283 plots move due to L259 value change. However using 7.1.4.0.0 on Ubuntu there are improvements and quick workarounds. If a file behaves like that test file, Users reading here may try the following. 6. The following actions all do cause Chart C283 to update once . . . . a. Move cell selection using keyboard < v ^ > to any cell with text or data. or b. Click on any cell with text or data. or c. Click on the Ubuntu desktop or d. Click on any other open application window. or e. Click on a menu (example Tools, Automatic Spell Checking) or f. Click on a row number or column letter (any row or column that has values) or g. Scroll the sheet to push out the chart then scroll back into view. but h. Clicking any empty cell on the sheet. . . .Chart C283 does not update. and i. The above methods cause the Chart at C283 to only update once. 7. The following action causes C283 to update automatically (dynamically) a. Double-click the Chart C283 area. (Single click is insufficient) b. Chart C283 is fully active for the User session (but not at next load). c. File>Save then >Open does not fully reactivate the chart (no repair). Testing another very large research file (100MB opens to 6GB), not attached here. It is a Diabetes research file saved but with no charts working at all. 8. 7.1.4.0.0 opens that very large file with all charts working :) Testing Dimitris' Options> OLE parameter solution (I change default 20 to 500) using the Ubuntu 18.04.2 LTS standard Calc bundle 7.0.4.2 9. All files here (and the attachment on this thread) all charts all work. I add this comment to help new visitors (USERS) with similar problems reading for the first time here. The new commit is a huge improvement. Abandoned or lost work can be resumed. For comments about file backwards compatibility problems (like mine) Bug 137735 If you notice different workarounds (or using Windows) please see Bug 141799 Personally, I can now upgrade all my work from the Calc 5.4.7.2 workaround to any Libreoffice 7 version (using Dimitris' parameter change - 20 to 500 works so far) and ask my collaborators to do the same on their PC. Comment 91
Excuse me. The Version below used is (I presume) including the commit. PC used for testing for comment 106 is without OpenCL capability. [For new readers wondering why OpenCL is off, when starting Calc, the application may blink a few times before showing; it's testing if the Ubuntu+graphics chipset can work reliably with OpenCL. If not, Calc continues without it]. Version: 7.1.4.0.0+ / LibreOffice Community Build ID: 99ca6b660fd911e9e60b63ae286c588aedfb01d0 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-04-21_07:55:21 Calc: threaded I've also tested much with Ubuntu 20.04 and the latest Dev/Calc 7.2.0.0 alpha; remarks on Bug report 141799 (to compare with Windows effects which are different).
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-1-3": https://git.libreoffice.org/core/commit/fdb0b1d3f94d3233d984f2f51ddd7e425e885acb tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Test results using attachment 165696 [details] all successful Test results with 100MB file (opens to 6G across two 4K monitors) all successful UBUNTU 18.04 LTS - Chart updates Version: 7.1.4.0.0+ / LibreOffice Community Build ID: e5b8477a1270a8b572b3815cfb318110eb19d0f2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-04-28_11:37:37 Calc: threaded UBUNTU 20.04 LTS - Chart updates Version: 7.1.4.0.0+ / LibreOffice Community Build ID: e5b8477a1270a8b572b3815cfb318110eb19d0f2 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:libreoffice-7-1, Time: 2021-04-28_11:37:37 Calc: threaded WINDOWS 10 PRO - Chart updates Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f616d96bd8ce8986e4cc204953db0467e6060b5c CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL Unexpected result - 7.1.3.1 was already on windows 10 PC 21/04/2021 so I tested it without yet updating beyond this build ID (without further commit) WINDOWS 10 PRO - Chart updates Version: 7.1.3.1 (x64) / LibreOffice Community Build ID: fa76d07d7006a0e2866c3247cef2d5eb55ae8369 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
More test results using attachment 165696 [details] - Chart updates Test results with 100MB file (opens to 6GB across two 4K monitors) all successful UBUNTU 20.04.2 LTS Gnome 3.36.8 Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 1325d8161a74a3cedc169952eca10f4343e700c4 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-04-28_00:26:19 Calc: threaded
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-0-6": https://git.libreoffice.org/core/commit/aef624769c2d7f401fd94864ba9824345e926a71 tdf#86321: Revert "Resolves: #i123539# some optimizations for 3D chart..." It will be available in 7.0.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from VLB) Step 1. Deleting values in H19:L19, All the charts update - is the expected result (there are fewer valid x scatter coordinates) Step 2. Click back using toolbar Undo: Delete All the charts update - is the expected result (there are all the x valid scatter coordinates) However, the trend lines on the charts are not restored to original state. Saving the file (different name), then open, the trend lines are in error. Step 3. Modify value I19 from 4 to 8, the trend lines are redrawn. Step 4. Click back using toolbar Undo: Input All the charts update - is the expected result The trend lines are now again at the file original start shapes. I see there's a macro in the file and I don't know enough about how the file works to comment further. So I'll investigate trend line behaviour with other files. Summary: with attachment 114246 [details] deleting values; the trend lines do not follow. Changing a value; the trend lines do follow and Undo functions also. In all tests the x,y scatter plots remove and move (but I think only VLB can confirm it's precisely as expected). Version: 7.0.6.2 (x64) Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
(In reply to matthewnote from comment #112) > Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from > VLB) > > Step 1. Deleting values in H19:L19, > All the charts update - is the expected result > (there are fewer valid x scatter coordinates) > Step 2. Click back using toolbar Undo: Delete > All the charts update - is the expected result > (there are all the x valid scatter coordinates) > > However, the trend lines on the charts are not restored to original state. > Saving the file (different name), then open, the trend lines are in error. > > Step 3. Modify value I19 from 4 to 8, the trend lines are redrawn. > Step 4. Click back using toolbar Undo: Input > All the charts update - is the expected result > The trend lines are now again at the file original start shapes. > > I see there's a macro in the file and I don't know enough about how the file > works to comment further. So I'll investigate trend line behaviour with > other files. Summary: with attachment 114246 [details] deleting values; > the trend lines do not follow. Changing a value; the trend lines do follow > and Undo functions also. In all tests the x,y scatter plots remove and move > (but I think only VLB can confirm it's precisely as expected). > > Version: 7.0.6.2 (x64) > Build ID: 144abb84a525d8e30c9dbbefa69cbbf2d8d4ae3b > CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: CL I can also see the behavior in LO 7.06 + 7.1.3 + 7.2 The behavior shouldn't happen and has nothing to do with the macro.
(In reply to VLB from comment #113) > (In reply to matthewnote from comment #112) > > Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from > > VLB) > > > > Step 1. Deleting values in H19:L19, > > All the charts update - is the expected result > > (there are fewer valid x scatter coordinates) > > Step 2. Click back using toolbar Undo: Delete > > All the charts update - is the expected result > > (there are all the x valid scatter coordinates) > > > > However, the trend lines on the charts are not restored to original state. > > Saving the file (different name), then open, the trend lines are in error. > > I can also see the behavior in LO 7.06 + 7.1.3 + 7.2 > The behavior shouldn't happen and has nothing to do with the macro. Thankyou. Well, (if it helps QA user testing?), I compare attachment 114246 [details] with Calc 7.1.3.2 on a dual-boot machine. On Windows, the trend lines become disorganised when a value is deleted. On Ubuntu 20.04 (identical Calc Build ID) the trend lines function with the expected result. On Ubuntu, after deleting or changing first sheet values in H19:L19, click Undo: delete. Those trend lines are moved and restored and saved correctly. Version: 7.1.3.2 (x64) / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL compared with Version: 7.1.3.2 / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Note: Opening a very large file here, the Windows setup takes 3 mins 30 seconds (uses 6GB) then displays. The Ubuntu setup takes 2 mins 12 seconds (really very fast!) :)
(In reply to VLB from comment #113) > (In reply to matthewnote from comment #112) > > Testing Calc 7062 on Windows 10 Pro using attachment 114246 [details] (from > > VLB) > > > > Step 1. Deleting values in H19:L19, > > All the charts update - is the expected result > > (there are fewer valid x scatter coordinates) > > Step 2. Click back using toolbar Undo: Delete > > All the charts update - is the expected result > > (there are all the x valid scatter coordinates) > > > > However, the trend lines on the charts are not restored to original state. > > Saving the file (different name), then open, the trend lines are in error. > > > > Step 3. Modify value I19 from 4 to 8, the trend lines are redrawn. > > Step 4. Click back using toolbar Undo: Input > > All the charts update - is the expected result > > The trend lines are now again at the file original start shapes. > > I can also see the behavior in LO 7.06 + 7.1.3 + 7.2 > The behavior shouldn't happen and has nothing to do with the macro. I find, here, that in Windows with Calc 7.1.3.2 the lines are correct with Tools>Options>OpenCL> deselect "Allow" (uncheck) Apply>Restart Now Open>Liggerv2.6. In other words charts work here with Windows OpenCL OFF. For QA. 1. It seems use of OpenCL(+Windows) is in error by introducing problem cells. If I uninstall Libreoffice (entirely) from Windows 10 Pro then install 7.1.3.2, then Help, Restart in Safe Mode, Reset to factory settings, Reset entire user profile, Apply Changes and Restart then OpenCL is enabled on this PC. 2. Open attachment 114246 [details]. Message appears "You are running...for first time" 3. roX0_9 is the open sheet. Go to invoer and delete H19:L19 (now empty). 4. Click back arrow Undo:delete. H19:L19 are now with values again. 5. On sheet roX0_9 last chart lines are in error. Cells DT52:DT153 are wrong. 6. Actual result; DT88 is showing a value of 59.441. 7. Expected result; DT88=DQ84 which is value = 0.1512. 8. Close file. Reopen file. Repeat steps 3 to 7; the error is the same. 9. However, Close File, Close Calc, Restart Calc, Open attachment. 10. Repeat steps 3 to 5. On sheet roX0_9 the DT column values are now correct. 11. On sheet invoer, the line for data range DT column is now wrong but it's DT column values (also on invoer) are correctly calculated and displayed. Observations. Use of CL with Windows on this PC is associated with cell values being wrong. Starting 7.1.3.2 twice then open the same file causes differently wrong than the first fresh install. Cell values become correct (although the file hasn't changed at all) with trend lines now in error (because the system has lost track of the full data range to be drawn). Data>Calculate>Recalculate does not update the DT52:DT153 values at step 5. Recalculate_Hard does cause the DT52:DT153 range to update. Option OpenCL OFF causes correct presentation of all charts and their data. Version: 7.1.3.2 (x64) / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Referring to new observation of cell value errors Comment 112 Comment 114 and Comment 115 I suggest moving those reports to Bugs about autocalculate instead. The Chart update is (in fact) working and shows calculation bugs. Bug 125320 Bug 125052 or Bug 128329 expressed in new Calc 7 versions also. With Windows + OpenCL allowed, Reset User Profile, Open attachment 114246 [details], delete H19:L19 then Undo: delete, there are errors in Sheet roX0_9 column DT (cell=other cell not being calculated). OpenCL creates .BIN files in LibreOffice or LibreOfficeDev >4>cache and OpenCL updates registrymodifications.xcu with many new rows At next Open attachment, the same procedure, delete H19:L19 then Undo: delete, Sheet roX0_9 is now calculated correctly, yet now there are errors in Sheet invoer (it's own column DT). The Chart at invoer M62 is updating it's trend line correctly, revealing incorrect calculation in the data range column DT. The User Profile updates coincides with the autocalculation (A=B) interruption and causes a new one on a different sheet (still opening the same file without editing the file, without saving the file). Maybe more than just a coincidence. This gives an impression of "sporadic fail". Because this is now reproduceable (with VLB's file) and with a User Profile reset manipulation and with OpenCL on/off reproduce and with Hard recalculate evidence. . . . . I suggest moving the report at comments 112, 114 and 115 to Bug 125320. User (pseudo b) and Telesto were waiting for a "reproduceable sporadic" demo. It may not be the only one but I think it's best written there. Would Buovjaga or Xisco agree or guide me please? Would VLB please consider permission that I copy his test file to Bug 125320? I intend to use it there and probably make a small screenshot video (asked for by Telesto, QA).
> Would VLB please consider permission that I copy his test file to Bug 125320? > I intend to use it there and probably make a small screenshot video (asked > for by Telesto, QA). Of course I agree
(In reply to matthewnote from comment #116) > I suggest moving the report at comments 112, 114 and 115 to Bug 125320. > User (pseudo b) and Telesto were waiting for a "reproduceable sporadic" demo. > It may not be the only one but I think it's best written there. > > Would Buovjaga or Xisco agree or guide me please? > Would VLB please consider permission that I copy his test file to Bug 125320? > I intend to use it there and probably make a small screenshot video (asked > for by Telesto, QA). If you think you have confirmation, then sure, set it to NEW.
(In reply to matthewnote from comment #116) > I suggest moving the report at comments 112, 114 and 115 to Bug 125320. > User (pseudo b) and Telesto were waiting for a "reproduceable sporadic" demo. > It may not be the only one but I think it's best written there. > > Would Buovjaga or Xisco agree or guide me please? > Would VLB please consider permission that I copy his test file to Bug 125320? > I intend to use it there and probably make a small screenshot video (asked > for by Telesto, QA). I took a brief look at bug 125320. The description and discussion there is already somewhat long and complicated. @matthewnote: If I understand correctly, that you can add a concise description of the bug and how to replicate it, along with a not-too-large test file - then how about creating a new bug and closing bug 125320 as a duplicate of the new bug report? Just an idea. The intention is of course to make a clean and accessible bug report, while keeping the track from bug 125320. But if important information will be lost (well, obscured) by that approach, then go on with the original bug.
Thankyou. For VLB, one last question here for you. Does Windows Calc7 Option OpenCL "disabled" (OFF) work for you with this file? It does on my PC, yet the topic depends on the computer hardware and drivers (I use Shuttle PCs with Intel). I'm hoping to work out one more thing (why OpenCL) before moving the Feedback Report. With OpenCL allowed,(ON), using Tools, Detective, trace precedents I studied the variable results on the invoer sheet Chart M66. In the steps described, after first start Calc, first load file, when delete H19:L19, invoer column DT calculates -27 for all cells DT52:DT157 but the chart displays a "sawtooth". At Undo: delete it's the reverse. . .column DT calculates a "sawtooth" but the chart displays the old values before the undo (mostly -27). In other words, the chart is updating but one action "late". If it's useful for you to see when the autocalculate block is occurring, at the first start of Calc, first load of file, first Undo: delete, using Data>Calculate>Recalculate_Hard the column EB cells (example EB58); =IF(EXACT(EA58,$X$68)=TRUE(),TRUE(),"") now update from WAAR to empty "". At that moment Chart M66 can/does adopt the values of the "sawtooth" in column DT. However, even if I delete all the column EB (save new file) and start again, the link between DT calculated and chart not-yet is still occurring. So EB column changes are interesting coincidence (visual) but the chart seems not to depend on that column. I find bug reports and histories of bugs in Calc concerning Grouped Formulae and Software Interpreter and OpenCL. (Skia seems to work! :) @VLB I hope that helps (to know about visual column cell clues while engineering) and that Calc7 OpenCL disabled works for you for this particular file (does it?). I promise I will soon cease posting on this thread ! : ) I (personally) am a very happy engineer now the charts update. Great!
(In reply to matthewnote from comment #120) I don't quite understand what is not going well, but I have the impression that it works for me with Wi 10 pro. However, I can find that recalculating column EB, that it does not recalculate at fresh start of file in some situation and that this column is recalculated only when saving and reopening. This mainly happens when I change cell E12 to value "C18" after starting file. With this I can recognize bug 125320.
(In reply to matthewnote from comment #120) hello matthew, as you are / had been struggeling with 'problems on load' tdf#140722 might be interesting, reproducible fail on load,
> However, I can find that recalculating column EB, that it does not > recalculate at fresh start of file in some situation and that this column is > recalculated only when saving and reopening. This mainly happens when I > change cell E12 to value "C18" after starting file. > > With this I can recognize bug 125320. Well; I think I've found the problem and the consequences (Charts are mixed up, showing data that's not in any column on any sheet) and why. I will write a bug report (if someone can please reproduce?), yet one item at a time. I'm sorry to use the word important in these steps. They're simple, but something very complex is occurring. You may not see the same effect because it all depends on version, windows, OpenCL and file history (user profile); so for anyone testing, it's very helpful if you describe what is different. It doesn't "have to" be the same effect. The steps are simple and only one (!) user action. I'm asking because I may be able to make a much bigger contribution about something else. 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] 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. [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. [At this stage, on this computer here, column EB and the chart M66 and all data on every sheet respond correctly about all functions :). It would be great if you could use the file intensely. Also, please let me know if E12 action is still a problem or resolved for you. I can do more. Step 19. (Important). Click Calc>Help>About>Version information button. Please right-click paste on your response here (or in email). Please attach here or email the "test repair by VLB" file from your PC. What you see or don't see (in columns and charts) depends on that information. @Buovjaga I write here about this rather than on the other Bug report because it concerns VLB's file. I hope someone reproduces this! Then I'll create a new Bug report. On this PC here, running Calc 7.2 on Windows 10 Pro, the == is tolerated (no Err:509 message)then code mixes up everything with big consequences. I will describe all effects but it includes charts showing data before the column (which is fun but very difficult to notice - I can notice because I use two 4K monitors). soffice then writes a ghost bug into the User Profile (I watch it using Windows security auditer). Then OpenCL mixes it all up again at next Calc start. In my report I hope to be precise including the User profile damage detail, line by line. Safe mode, factory settings gives yet another mix (doesn't make it worse, doesn't help the user, just different again). It's easy to suggest "include a new syntax check for == and show code 509, commit, bugfix, finished". I'll start the new bug report (after someone reproduces). I've seventy simplified versions of VLB's file, also to find out if it's Ooo or Calc 4 and so forth. Yet, it's a lot more useful to find out all the possible causes of sporadic fails and hard recalculate. Perhaps I can contribute on that story (it's possible). But I do need a "reproduce" windows 10, OpenCL allowed (from someone else). @Buovjaga The technique I used to find the == syntax in AM38 was by inspecting every single cell in VLB's file. Really. Detective has it's limitations but helped a lot. I started on the last sheet (eliminating dependents for everything but one trend line). The precedent tracing was a colossal workload. Then I put everything on one sheet (which was extraodinarily difficult, yet entirely logical). Nothing in the file broke; I saw some odd behaviour when removing redundant named expressions but still couldn't actually break the file. Great work Frank! I don't know why I'm laughing now! Because Calc doesn't know to criticise == it just seemed likely that I was searching for something that I didn't know either. Well, the work exonerates Group Formulae (for this case) and a hundred other calc features - so no regrets! AM38 doesn't actually have any dependents. == probably caused by keyboard bounce (I use only logitech products). == (and other strangers) might be introduced by software, but checking 300 000 cells, I didn't see evidence of keyboard firmware or language problems. VLB uses greek and dutch (I think) but it all works. I don't know of any other choice than cell by cell check when the problem is unknown (to the software also). I divided up the task (of course); point is . . to learn from this . .is there any particular technique or tool that a User might consider, that you prefer for this type of investigation? For 125320 , I've prepared Virtual Studio and debug to learn how that helps.
I'm using this version and using == as a deliberate infection to diagnose further. Thinking positive! Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1675a68526c43c6c6e4dc850ee911f0c1de75c88 CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Created attachment 172401 [details] Opgeslagen bestand na test door VLB Behoort bij comment 125.
> 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. > > [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. > > [At this stage, on this computer here, column EB and the chart M66 and all > data on every sheet respond correctly about all functions :). It would be > great if you could use the file intensely. Also, please let me know if E12 > action is still a problem or resolved for you. I can do more. > > Step 19. (Important). Click Calc>Help>About>Version information button. > Please right-click paste on your response here (or in email). Please attach > here or email the "test repair by VLB" file from your PC. What you see or > don't see (in columns and charts) depends on that information. > Version: 7.1.3.2 (x64) / LibreOffice Community Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1 CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: nl-NL Calc: CL I have gone through the steps and can indicate my findings: In steps 8 and 9, the value will go back in column EB for me. At step 10 I see 1 line that does not go back in a sawtooth. After performing step 18, the graph in step 10 is displayed correctly. I added the saved file as an attechment.
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.
Thankyou. Generated new Bug 142556, set to NEW. I'm not sure about priorities for "User hell" so accepted the default.
(In reply to Xisco Faulí from comment #96) > Hi, > My patch in comment 95 fixes the steps in comment 28. For other issues, > please, fill a new report. Closing as RESOLVED FIXED Hi After testing with my contributed attachment, I returned to test VLB's attachment some more. Use of undo:delete caused data range errors yet charts mostly followed (including plotting those errors) Yet now I analysed that a chart also fails to update in one circumstance. It's a mix of symptoms yet I hope the work offers a vital clue (maybe). Created Bug 142891