[Libreoffice-bugs] [Bug 125320] - sporadic fail! - combination of autocalculate and shared formulae still broken in 6.3.0.0.alpha1+ with threaded off

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Wed Jan 6 09:18:16 UTC 2021


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

matthewnote at yahoo.co.uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matthewnote at yahoo.co.uk

--- Comment #15 from matthewnote at yahoo.co.uk ---
Created attachment 168720
  --> https://bugs.documentfoundation.org/attachment.cgi?id=168720&action=edit
example faulty file to reproduce deeper issue

I think I can provide the test file and it explains why users have a very
difficult task to reproduce.  This is reproduceable if readers can bear with
me.
The demonstration requires a version before bug fixes, patches (and attempts)
concerning autocalculate to see the problem. So I use Calc 5.  It is quite
extraordinary (in my experience) and indicates a short-circuit somewhere with
the graphics tasks.  That version is needed to look "under" the patches and
commits.
Demonstration on Ubuntu 18.04 LTS with Calc 5.4.7.2.

Step 1.  Open Calc 5.4.7.2, new sheet, set the Window to show columns A to half
of column W (narrow field of view of the Libreoffice application window).
Step 2.  Restart Calc 5.4.7.2, open example file (shows oilolive_3 columns A to
V and half of column W in the visible window).
Step 3.  Stay on oilolive_3 sheet.  If browsing the file to learn the basic
controls, the bug will not reproduce.  Go back to step 1 when ready.

Note;  sheets oilolive, oilolive_2 and _3 are all identical twins.  Raw data is
at  rows 500 to 600, columns A to K.  Then the data is repeated upward in
blocks including one statistical formula group (exponential smoothing).  The
user selects raw/filtered data using 1 or 0 at cell $A$5 to place useful
results in C6 to AC112.  In the example file, that choice comes from a user
control on PLOTXYdum sheet (x,y scatter chart removed to make simple).  Then
the 1 or 0 is sent to the INDEX sheet then copied to $A$5 on all data sheets
for the IF choice.

Step 4.  Observe the sheet oilolive_3 has cell L6 set =C6.  Cell U6 also set
=C6.
They have different results.  The same is the situation for all the rows. 
(Content.xml confirms the file was saved with different conclusions about the
calcext format compared to openoffice result).  How to reproduce this defect
will take me some time - but the next steps reveal why (I hope!).

Note; Commits up to Calc 7 have patched this and other autocalculate issues.  I
know.  Also, Hard calculate (Shift Ctrl F9) works with Calc 5 and will refresh
all the sheets if the user notices the problem.  For this reproduce, it's
assumed the user doesn't notice so continues. . . . so please look at the
foundation problem as follows:

Step 5.  Stay on oilolive_3 after opening the file columns A to V in view
without recalculate.  That will be provoked in step 6.  PLOTXY_2 is
superfluous;  so . .
Step 6.  Right-click sheet tab PLOTXY_2 then Delete Sheet, confirm Yes.
Step 7.  Sheet PLOTXYdum is now viewed and last sheet.  Keep the window size
(no change to the application frame on the desktop).
Step 8.  Click once on oilolive_3.  Columns U,V etcetera are all updated by
triggered automatic recalculate (is the expected result).
Step 9.  Click once on oilolive_2 (must be the first occasion it's viewed).
Step 10. Columns U and V are not updated.  
Step 11. However, click and slide the horizontal scroll bar and drag it right. 
The columns beyond the application window on oilolive and oilolive_2 were
updated at Step 6. 

Expected result:  formulae and cell values are loaded and modified and saved
completely independently of the user view on his desktop, whether
autocalculate, hard recalculate or bugfixes are triggered or not.

Actual result:  there seems to be a short-circuit between calculate and the
graphics layer cache.  The user saves a file with "mixed" cell states depending
on where he was viewing.

I understand (experience in realtime processing software debugging) that we can
economise on RAM and processor time if (and when) it's acceptable to "only
prepare/show in the window".  I notice Libreoffice does this economy with
charts that redraw as the scrollbars are moved (CPU% and memory useage
increases/decreases).  That's quite a good idea.  I'd like to switch that off
(because I can use 32GB, no problem) but understand the economy for smaller
PCs.

I've never seen autocalculate decision based on application Window frame view -
and outside the view.  Please advise me of documentation or how to learn about
graphic layers interface Libreoffice to Calc to Ubuntu to do more about this. 
b has offered 150 dollar prize!

-- 
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/20210106/ca5f0f0e/attachment.htm>


More information about the Libreoffice-bugs mailing list