[Libreoffice-bugs] [Bug 86321] EDITING, FORMATTING: diagram didn't automatic update when change variable (steps in comment 28)

Fri May 28 06:50:53 UTC 2021

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

--- Comment #123 from matthewnote at yahoo.co.uk ---
> 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
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.

-- 
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/20210528/35856ea0/attachment-0001.htm>