https://bugs.documentfoundation.org/show_bug.cgi?id=171017
Bug ID: 171017
Summary: CALC ARRAY formula using INDEX appears to corrupt
references when complete rows in the source or
destination are removed
Product: LibreOffice
Version: 7.5.9.2 release
Hardware: All
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
Description:
Initially, I'm uncertain whether I'm trying to achieve the impossible due to
the complexity of Array and Index functionality. However, it does appear to
function as I intend it to - providing I get it right first time. The
corruption of cell values was only discovered when I attempted to cut the sheet
down to about ten valid analysis rows and a reduced number of source rows.
Consequently, the entire sheet is attached but the source data was simply cut
and pasted data only to avoid reliance upon the other sheets in the file.
The attached PNG identifies the initial areas of "confusion".
The attached CALC and simple image will help to explain what may be multiple
issues.
After each test iteration it is wise to exit and reload the file to continue
the test as the undo stack is also corrupted by the following actions. I
haven't experimented to see how actually saving the file affects the remaining
portions of the test.
There are two distinct and separate tables:-
A:Q is the source data but the data and calculations performed in J:Q are
irrelevant
S:AE is for target analysis but only S:Y is impacted - knock-on errors are
expected
1) If the "slicer" at the top of the array is utilised FOR SORTING there is a
warning that the activity cannot take effect on only part of an array but
selecting a target value is acceptable and will produce a filter.
2) entering an "ID" number in Z3 to drive the lookup will produce data but if
the ID is then deleted or undone, not all the recipient cells return null.
3) if A3:Q5 are selected and removed from the data source with [Ctrl]+[-] &
shift up then the first and second rows of the return are "nulled" and Indexing
appears to re-index with "random" numbers in the formula - See the PNG. The
entire array fills with the first number encountered in the source data.
Undoing prior editing doesn't revert to the original values.
4) Selecting and removing Analysis rows S4:AE4 with [Ctrl]+[-] & shift up has a
combination effect. The rows appear to remove correctly but when the action is
undone, ALL the data rows below the reinstatement adopt the refill
characteristics at 2) above.
Steps to Reproduce:
1. follow the instructions at 1) in the description
2. follow the instructions at 2) in the description
3. follow the instructions at 3) in the description
4. follow the instructions at 4) in the description
Actual Results:
The corruption and loss of undo buffer identified in the description
Expected Results:
Reproduction of the source data in the analysis array
Reproducible: Always
User Profile Reset: No
Additional Info:
Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster;
VCL: win
Locale: sv-SE (en_SE); UI: en-GB
Calc: threaded
Following is the earliest version I am able to investigate
Version: 7.5.9.2 (X86_64) / LibreOffice Community
Build ID: cdeefe45c17511d326101eed8008ac4092f278a9
CPU threads: 12; OS: Windows 10.0 Build 26200; UI render: Skia/Vulkan; VCL: win
Locale: en-GB (en_GB); UI: en-GB
Calc: threaded
--
You are receiving this mail because:
You are the assignee for the bug.
