[Libreoffice-bugs] [Bug 81757] Calculations order do not follow cell dependencies

[bugzilla-daemon at bugs.documentfoundation.org]

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

--- Comment #18 from b. <newbie-02 at gmx.de> ---

! improvement found, danger of passing away, i'd appreciate a quick recheck !

quick: check this bug with ver. 6.2.7.1 winx64 or 6.2.8.2 winx64, for me it
looks gone. 

danger: it is showing up again in subsequent versions, 
some tested: 6.5.0.0.a0, 6.4.0.1, 6.4.0.3, 
and even 
7.0.0.0.alpha0+ (x64) Build ID: 07b1159b79135857dd9a450c3bb9ae0a944ebcf9
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default;
VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: 
all failed, 

thus 'regression'? maybe easier to catch now than later. 

sorry, for a correct detailed description this post will become long, imho it's
important to read and to check! 

steps to reproduce: 


A): to see the fail: 

1. use one of the buggy versions mentioned above (or to test any other), 

2. load attachement 'file with problem': 

https://bugs.documentfoundation.org/attachment.cgi?id=103462

3. allow macros, 

4. enable 'edit document', 

5. use the dropdown box spanning from D6 to F6 to select a material, 

5a. in some situations the box is in 'design mode' and cant't be used for
selection, that can be corrected by 'view - toolbars - form controls' and then
deselct 'design mode' in the (often floating) toolbox, 

6. after changing the selected material to another metal observe I7 and I8
showing wrong - outdated - values, 

(acc. to the formula they should show the same values as F7 and F8 while I4 is
'1', when the error kicks in they are 'one cycle off' as described in other
comments for this bug)

7. note that the displayed values in I7 and I8 only appear to be correct if you
select the same material again, 

(it only looks! that way because new and former calculation produce the same
result), 

8. observe that after changing to another materal again the values in I7 and I8
are wrong again, 


B): to see the fix: 

1. use ver. 6.2.7.1 winx64 or 6.2.8.2 winx64, 

... proceed as above ... 

6. in this step after changing the selected material to another metal observe
instant reaction to correct values in I7 and I8, 

7. play around as you like, I7 and I8 follow correctly, 

--- i can't say! --- 

- if this better behaviour is intentional (a patch?), by chance (side effect of
another patch?) or just randomly, depending on my mood or room temperature, 

- if this behavior is stable or will disappear tomorrow, 

(did some criss-cross checks and rechecks, looks stable at the moment)

- if this behaviour is a 'full solution' or just affects this one flavour of
something more general? 

thus i'd like a recheck by other testers, and if i was lucky to spot a nugget
that someone invests the effort to nail it down and port it to the actual
releases ... 

reg. 



b. 

P.S. fault looks independent of the settings for parallelization ('threaded' or
openCL) in all versions, 

P.S.II. the 'problem' with J12 and the need of 'iterations' from c#7 (which
have not been neccessary in older versions?) are still present ...  

P.S.III as the better behaviour for this bug kicked in with ver. 6.2, while bug
#129199 with somewhat similar description newly appeared in those versions, i
assume them being 'related', unfortunately we have both problems active in 6.4
versions :-( ... thus it's not a simple toggle in recalc ordering?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200219/a3e81da1/attachment-0001.htm>