Bug 86321 - EDITING, FORMATTING: diagram didn't automatic update when change variable (recalculation not triggered)
Summary: EDITING, FORMATTING: diagram didn't automatic update when change variable (re...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All All
: highest minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
: 87383 87622 90083 90674 91931 (view as bug list)
Depends on:
Blocks: Chart
  Show dependency treegraph
 
Reported: 2014-11-15 20:41 UTC by vlb
Modified: 2018-10-31 17:25 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Issue graphic (1.91 MB, application/vnd.oasis.opendocument.spreadsheet)
2014-11-15 20:58 UTC, vlb
Details
Latest Issue graphic (2.39 MB, application/vnd.oasis.opendocument.spreadsheet)
2015-03-22 14:13 UTC, vlb
Details
Screenshot from rox0_9 after deletion in invoer H19:L19 (48.77 KB, image/jpeg)
2015-03-28 15:38 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description vlb 2014-11-15 20:41:18 UTC
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.
Comment 1 vlb 2014-11-15 20:58:30 UTC
Created attachment 109539 [details]
Issue graphic
Comment 2 vlb 2014-11-15 21:05:35 UTC
(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".
Comment 3 Joel Madero 2014-11-16 20:27:49 UTC
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
Comment 4 vlb 2014-11-16 22:08:49 UTC
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.
Comment 5 vlb 2014-11-22 13:14:48 UTC
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.
Comment 6 vlb 2014-11-23 10:42:06 UTC
Referring bug 86572 and do hard recalc CTRL+SHIFT+F9 than the graphic is oke.
Comment 7 raal 2014-11-23 11:10:13 UTC
*** Bug 86572 has been marked as a duplicate of this bug. ***
Comment 8 raal 2014-11-23 11:11:44 UTC
Problem with automatic recalculation.
Comment 9 vlb 2014-11-23 11:41:34 UTC
(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.
Comment 10 vlb 2014-11-26 19:06:07 UTC
(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!
Comment 11 vlb 2014-11-30 09:14:24 UTC
(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.
Comment 12 Julien Nabet 2014-11-30 15:59:25 UTC
MAB => highest (see https://bugs.freedesktop.org/show_bug.cgi?id=84480)
Comment 13 raal 2014-12-17 17:51:34 UTC
*** Bug 87383 has been marked as a duplicate of this bug. ***
Comment 14 Francisco 2015-03-21 16:12:22 UTC
I have experienced this bug also. As Workaround, I simply move the chart into another position.

Regards
Comment 15 Joel Madero 2015-03-21 16:40:15 UTC
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.
Comment 16 vlb 2015-03-22 14:13:56 UTC
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
Comment 17 vlb 2015-03-22 14:18:38 UTC
I hope the issue can solved.
Comment 18 Joel Madero 2015-03-22 16:04:49 UTC
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
Comment 19 Matthew Francis 2015-03-27 15:48:43 UTC
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
Comment 20 Matthew Francis 2015-03-28 02:10:19 UTC
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)
Comment 21 vlb 2015-03-28 13:15:32 UTC
> @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
Comment 22 vlb 2015-03-28 13:38:55 UTC
> 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!
Comment 23 Matthew Francis 2015-03-28 13:43:45 UTC Comment hidden (obsolete)
Comment 24 vlb 2015-03-28 13:47:35 UTC
(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
Comment 25 Cor Nouws 2015-03-28 14:03:54 UTC
(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
Comment 26 Cor Nouws 2015-03-28 14:04:51 UTC
(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*
Comment 27 Buovjaga 2015-03-28 15:38:27 UTC
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
Comment 28 Matthew Francis 2015-03-28 16:21:25 UTC
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.
Comment 29 Matthew Francis 2015-03-28 16:26:04 UTC
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.
Comment 30 Cor Nouws 2015-03-28 19:54:15 UTC
(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"
Comment 31 Matthew Francis 2015-04-03 04:32:31 UTC
*** Bug 90083 has been marked as a duplicate of this bug. ***
Comment 32 Matthew Francis 2015-04-23 09:33:44 UTC
*** Bug 90674 has been marked as a duplicate of this bug. ***
Comment 33 Matthew Francis 2015-04-23 11:56:53 UTC
*** Bug 87622 has been marked as a duplicate of this bug. ***
Comment 34 tommy27 2015-06-27 06:11:44 UTC
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
Comment 35 vlb 2015-06-29 18:40:04 UTC
(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.
Comment 36 Matthew Francis 2015-08-14 02:45:14 UTC
*** Bug 91931 has been marked as a duplicate of this bug. ***
Comment 37 Robinson Tryon (qubit) 2015-12-13 11:11:02 UTC Comment hidden (obsolete)
Comment 38 Xisco Faulí 2017-09-11 08:59:29 UTC
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.
Comment 39 Mike Kaganski 2017-11-07 10:42:35 UTC
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).
Comment 40 Eike Rathke 2017-11-14 17:27:18 UTC
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?).
Comment 41 vlb 2017-12-20 13:06:20 UTC
I have test with the latest version LO 6.0.0.0beta 2 and it is still present.
Comment 42 vlb 2018-05-30 20:13:45 UTC
I have test in Versie: 6.0.4.2 (x64)and is still present.
Comment 43 matthewnote 2018-10-31 17:25:35 UTC
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.