I hope to be guided to the most fundamental documentation about this topic. I may then be able to improve the question and get much more brief. The aim is to be able to improve (or even resolve here) six Bug reports, notably 86321 (charts not updating) yet several others. To do that, it’s necessary to provide a method to reproduce, which (for some bugs) is almost (yet not quite) beyond the user. We generate spreadsheets using much copy and paste and find out later that cells are no longer calculating. I’m aware of about ten bug fixes for grouped formulae, triggers concerning autocalculate, hard recalculate and so forth. Also aware that more recent versions of Calc may be configured to not recalculate old files so as not to change the result seen by two different users with different Calc versions. Well, that’s the context for the question.
Reason to ask. Investigating Calc 5, 6 and 7 versions it’s evident that LO 7 incorporates quite a few fixes, yet as newbie 02 (b) observes, that seems to be masking something in the foundations that’s not yet adressed. I have about ten files to investigate with different symptoms.
For example, one will load, as usual viewing the last sheet from the last Save. It opens with half the formula cells showing zero. The formats check out as correct, there are other cells with absolutely identical formulae showing the true result. The content.xml reveals two different conclusions about precisely the same formula. Recalculation (to update the cells in limbo) can be triggered by toggling a cell “early” in the sequence, one that has “data validity” criteria (1 or 0; supplying an IF choice on every sheet which simply fetches raw data or analysed data). Or, one can also trigger the calculation by toggling once Calc>Tools>Options>Libreoffice Calc>Calculate>Iterations to on then off. The file and content.xml actually contain no circular references yet can be stimulated to show the result. In this particular case, Hard Recalculate also works.
However, some bugs resist these methods, notably when charts are involved. Most odd (about the example) is that twin (identical) sheets not yet viewed are recalculated, yet only for cells that are outside the application window view area. After recalculate, clicking onto those sheet tabs, cells in the viewing area (often columns A to W) are still at zeroes. It seems recalculation depends on the sheet having already been viewed before (at least once, even if nothing is done on that sheet). Yet, surprise. Sliding the horizontal scroll bar reveals . . . . columns X, Y, Z, AA, AB etcetera have been done. Very odd. Not because they’re in the view area - rather because they’re out of it.
If the user doesn’t notice, cells out of view are being processed differently than those in the application window. If the file is editted and saved several times, the “mix” of calculated or not-yet is cemented into the ods content.xml. When reopening, a user hasn’t a clue how that occurred and very little chance to provide steps to reproduce. The “buggy cells” are all over the place, depending on how he or she was opening sheets (or not) and sliding the viewing area.
I did notice, because I’ve chosen to work two 4K monitors with a new habit of stretching out a window. If using two files, I’ll narrow one window down a bit.
In Bug report 86321 a developer (Eike) remarks that perhaps the consequent failures to update charts is “not a Calc problem” and another developer notes that the bug occurs (or not) depending on whether certain sheets have been visited/viewed at least once already. Libreoffice 5 versions will open while refreshing all charts (which LO 7 still doesn’t achieve). Yet LO 5 Calc user experience is that once you start inserting, copying or moving sheets there’s a sort of “patchwork” of valid and invalid views.
To work this out, I hope to learn about the rules for File>Load; going as far back as necessary. I do notice that soffice.bin is attributed memory getting progressively larger with each sheet opened/viewed and expect the software is attempting to be economical in memory and load times. Furthermore, I’m aware that Advanced settings - cache memories have been discussed at length. Does a remark “else than a Calc problem” mean it’s a global setting of Libreoffice that Calc developers don’t touch or a Linux kernel factor or something to do with gnome, gtk, windows or hardware (my computers have integrated Intel graphics that use the main RAM, somehow set aside for that avoiding collision with other applications - it seems).
I see the cache parameters are discussed on asklibreoffice (and not Bugs) so hope my question is appropriate here. I hope to learn deeper principles about how the cell/viewing is prepared in software - since the very beginning of Open office. I do (of course) reset user profiles, test factory setting and test everything on at least three versions of Calc, using Ubuntu 18, 20 and Windows 10 Pro. Some who have these bugs have also reported “the Bug’s still there” and then “I restarted this morning and it’s gone”. In theory, one load of a file is identical to another. To work that out, a bonus would be if I can learn how to inhibit/bypass original or recent file load economies software modifications. Here, it doesn’t matter how much RAM is used nor how long it takes (I’ve 32GB and 4.2 GHz). Then I might be able to improve the Bug reports and win 150 dollars from newbie_02 (b). I don’t code, but I do understand specifications, the older the better.