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]
(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,
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.
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 220.127.116.11 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 LO18.104.22.168beta1 and are correct calculation in LO 4.3.4.
Bug 86321 are the graphic's not recalculation in LO4.3.4 and LO22.214.171.124beta1.
(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 LO126.96.36.199beta1 and are
> correct calculation in LO 4.3.4.
> Bug 86321 are the graphic's not recalculation in LO4.3.4 and LO188.8.131.52beta1.
I have test in daily build Version: 184.108.40.206.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.
This is not a critical bug - I'm not sure who marked it as such.
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
Author: Bjoern Michaelsen <email@example.com>
Date: Wed May 21 08:57:55 2014 +0000
Author: Markus Mohrhard <firstname.lastname@example.org>
AuthorDate: Tue May 20 23:59:55 2014 +0200
Commit: Markus Mohrhard <email@example.com>
CommitDate: Wed May 21 01:50:44 2014 +0200
Following the instructions in Comment 16, this works for me again since
Author: Zolnai Tamás <firstname.lastname@example.org>
AuthorDate: Mon Aug 11 14:27:16 2014 +0200
Commit: Markus Mohrhard <email@example.com>
CommitDate: Fri Aug 29 17:40:29 2014 +0200
This OpenGL window is useless
After this commit, the indicated chart updates after step 3, with no manual recalculation required. LO 220.127.116.11 also works as expected.
I also tested a build of 5c3f47e44c2a734bddd0c3fb7f1151d5096ac494 as mentioned in comment 10, and the chart updated as expected there too.
- 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)
> - 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 18.104.22.168
> - If that doesn't work, please try following the instructions in
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 22.214.171.124 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 126.96.36.199 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
(In reply to Matthew Francis from comment #23)
> @vlb: Could you let us know what platform (OS) and version you're using
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 188.8.131.52 Build ID:
> and here is the same problem, by do the steps in comment 16!
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"
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
(you may mail me and explain in Dutch what is going on, if you prefer.)
(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: 184.108.40.206
Build ID: 45e2de17089c24a1fa810c8f975a7171ba4cd432
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:
Author: Noel Grandin <firstname.lastname@example.org>
Date: Thu Dec 25 15:17:55 2014 +0200
fdo#84938: convert IMPORT_ constants to 'enum class'
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 email@example.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
I have take the steps in comment 25 with attachment "Latest Issue graphic" with LO 220.127.116.11 and the graphic didn't correct update.
When i use LO 18.104.22.168 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)
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 22.214.171.124beta 2 and it is still present.
I have test in Versie: 126.96.36.199 (x64)and is still present.
Charts not updating (x, y scatter plots) is still present in Version: 188.8.131.52 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: 184.108.40.206 (x64)still present.