Bug 82414 - FORMATTING: R1C1 notation is not immediately updated for reverse ranges (as is the case for A1 notation)
Summary: FORMATTING: R1C1 notation is not immediately updated for reverse ranges (as i...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.5.7.2 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-10 08:48 UTC by Owen Genat (retired)
Modified: 2015-09-06 23:11 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
ODS showing before and after cell range notation under LOv4400 2014-08-08 (22.79 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-08-10 08:48 UTC, Owen Genat (retired)
Details
Screenshot (before) of ODS showing displayed values under LOv4400 2014-08-08 (9.06 KB, image/png)
2014-08-10 08:50 UTC, Owen Genat (retired)
Details
Screenshot (after) of ODS showing displayed values under LOv4400 2014-08-08 (8.79 KB, image/png)
2014-08-10 08:51 UTC, Owen Genat (retired)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Owen Genat (retired) 2014-08-10 08:48:31 UTC
Created attachment 104376 [details]
ODS showing before and after cell range notation under LOv4400 2014-08-08

Problem description: This report relies on using Multiplan / Lotus-123 / Excel R1C1 notation. I am raising the bug to get confirmation / clarification of: 

a) Whether certain cell range references should be preserved as entered or if it is OK for Calc to change the entered cell range reference between save, close, and re-open of the ODS.
b) Whether the included cell range references using R1C1 notation are considered valid.

I am happy to raise a separate bug if it becomes apparent there are two separate issues. I have raised this report due to this forum thread:

http://en.libreofficeforum.org/node/6199

... where a long-time user of R1C1 notation is indicating problems in recent versions of Calc. I have included the thread for reference only as it does not include much in the way of a simple or clear example (hence this report).

The attached ODS contains numbers 1 to 3 in rows 1 to 3 across 4 columns. Each column of figures is summed using a different type of cell range notation:

R[-3]C:R[-1]C - column 1
R[-1]C:R[-3]C - column 2
R[-3]C:RC     - column 3
RC:R[-3]C     - column 4

It is not clear to me which are valid forms from the old Multiplan / Lotus-123 / Excel days, but each would appear at least understandable. For convenience I have displayed each formula (as entered) on row 5, labelled "before". Beneath this in row 6 (labelled "after") is what each cell in row 4 contains after saving, closing, and re-opening of the ODS.

Steps to reproduce:
1. Tools > Options... > LibreOffice Calc > Formula > set Formula syntax to "Excel R1C1".
2. In a new file enter the numbers 1,2,3 in rows 1,2,3 respectively.
3. Copy these across 4 columns.
4. Beneath each column enter one of the indicated types of cell range reference in a SUM() function e.g., in R4C1 enter =SUM(R[-3]C:R[-1]C) in R4C2 enter =SUM(R[-1]C:R[-3]C) and so on.
5. Note values displayed are: 6, 0, Err:522, and 0 (most of which seem erroneous).
6. Save the file (ODS).
7. Close file.
8. Re-open file.

Current behavior: Contents of R4C2 and R4C4 are altered and resultant sums displayed are different (6, 6, Err:522, Err:522).

Expected behavior: Entered values are preserved and range references add as expected.

Tested under Crunchbang 11 x86_64 using v4.4.0.0.alpha0+ Build ID: 4d635dcae4d7275d04a17a0efc11b0531d5d0a82
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-08-08_23:24:32.

Behaviour is the same under these versions also:

- v4.2.6.2 Build ID: 185f2ce4dcc34af9bd97dec29e6d42c39557298f
- v4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0

Under v4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a the initially entered cell range still reverts after save, close, re-open, but the initially displayed values do not change i.e., 6, 6, Err:522, Err:522. This would seem to indicate at least a change in calculating the resultant value during the v4.2 series.
Operating System: Debian
Version: 4.4.0.0.alpha0+ Master
Comment 1 Owen Genat (retired) 2014-08-10 08:50:56 UTC
Created attachment 104377 [details]
Screenshot (before) of ODS showing displayed values under LOv4400 2014-08-08
Comment 2 Owen Genat (retired) 2014-08-10 08:51:31 UTC
Created attachment 104378 [details]
Screenshot (after) of ODS showing displayed values under LOv4400 2014-08-08
Comment 3 m_a_riosv 2014-08-10 12:44:04 UTC
I think none of both issues has nothing to do with R1C1, both happen with Calc A1 notation.

1 - Circular reference error is not showed when self reference is at the beginning D4: =SUM(D4:D1) doesn't show the error, D4: =SUM(D1:D4) yes.

2 - Redo references to always begin with the lower reference after save and reopen, I think the bug is that is not done when the formula is entered like in 4.3.1.0.0+ and previous.

IMO maybe better, change this for one and open another for the other, or close this one and open two new.
Comment 4 m_a_riosv 2014-08-10 12:55:07 UTC
Rethinking about it, if the second is solved the first can't happen. So maybe only this one can serve, changed the title with a description for the second.
Comment 5 Owen Genat (retired) 2014-08-11 02:56:13 UTC
(In reply to comment #3)
> 1 - Circular reference error is not showed when self reference is at the
> beginning D4: =SUM(D4:D1) doesn't show the error, D4: =SUM(D1:D4) yes.

Yes, thanks. I think this means that the examples in columns 3 and 4 are not valid. I should have worked that out for myself, so apologies for this. Please ignore these columns in the attachment.

> 2 - Redo references to always begin with the lower reference after save and
> reopen, I think the bug is that is not done when the formula is entered like
> in 4.3.1.0.0+ and previous.
> 
> IMO maybe better, change this for one and open another for the other, or
> close this one and open two new.

(In reply to comment #4)
> Rethinking about it, if the second is solved the first can't happen. So
> maybe only this one can serve, changed the title with a description for the
> second.

I am going to do this. I see now that the problem here is that the change in formula is not made immediately upon entering e.g.,

a) =SUM(R[-1]C:R[-3]C) to =SUM(R[-3]C:R[-1]C)
b) =SUM(A3:A1)         to =SUM(A1:A3)

Case (a) does not occur until file save, close, reopen; case (b) occurs immediately upon entering the formula; so there is inconsistency. It would be good if this could be made consistent. Thanks for helping me think more clearly about this. Status set back to UNCONFIRMED. Summary amended for clarity.
Comment 6 Owen Genat (retired) 2014-08-11 11:43:51 UTC
Changed FILESAVE to FORMATTING in summary. Also confirmed in v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b and so have set Version accordingly. Possibly Inherited from OOo.
Comment 7 QA Administrators 2015-09-04 02:49:20 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.0.5 or later)
   https://www.libreoffice.org/download/

   If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
 
 If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug 
3. Leave a comment with your results. 

4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword


Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-09-03
Comment 8 m_a_riosv 2015-09-06 23:11:59 UTC
Change the range order for the lower first with R1C1 notation.
Wors for me with:
Win10x64
Version: 4.4.5.2 Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
Version: 5.0.2.1 (x64) Build ID: 9a18d52abbdfbdc2ac9acebec2b92e7859eb73b7