GNOME Bugzilla – Bug 360849
clipboard, gnumeric format: problem with absolute addresses.
Last modified: 2018-05-22 13:17:42 UTC
Enter the following data: A1: 1 A2: 2 A3: =$A$1+$A$2 3 is displayed Select A1:A3 and copy to clipboard. Start another gnumeric process. Place cursor in B1 and paste. 0 is displayed in B3, and the cell contains =$A$1+$A$2, exactly as in the source. This behaviour is the same for pasting between two different gnumerics over the X or Windows clipboard, and between two workbooks in the same gnumeric process. You asked for it, you got it, but this makes no sense. The formula has nothing to do with A1 and A2 in the *destination* sheet. There are three interpretations that *would* make sense. a) Refer to A1 and A2 in the source sheet/workbook. Sometimes, this would be what the user intended, but probably not most of the time. There are too many problems to make this the default: What do we do with sources which haven't been written to disk? Moving either the source or the destination workbook would break stuff, etc. b) Transform absolute references to cells inside the source range to absolute references to cells in the destination. In this case: =$B$1+$B$2 c) Replace absolute references outside the source range with their values. So B3 would become =1+2 or 3. b) may be closest to what the user expects, but c) would also be better than what we are doing now. This is closely related to the issue in 360666: dependencies not taken into account when exporting via clippboard. OpenCalc is no better than Gnumeric in this respect. $A$1 in the source becomes $A$1 in the dest. You see one consequence of this in charts. When you build them by marking data and using the wizard, data series have absolute addresses. So if you mark a chart and all the data it is based on, and paste it into another gnumeric, the copy of the chart will look nothing like the original. Unless you happen to paste it into the same cell in the destination. One final twist: When copying charts, there is a difference between copying between two gnumerics and between two workbooks in the same gnumeric. Between gnumerics, the data series 'Sheet1!$A$1:$A$3' is copied unchanged. Between workbooks in the same gnumeric, a reference to the source workbook is added: '[../../../home/jk/gnome/chart.gnumeric]Sheet1!$A$1:$A$3'. I.e. solution a) above. This is fragile!
I guess b) is problematic, too - transforming absolute references to cells inside the source range to absolute references to cells in the destination. The difference between cut/paste inside a workbook and between workbooks would be surprising. Excel 2003 behaviour: - Between different instances of Excel: - All cells are copied as values. - If the selection includes both cells and a chart, the chart is left out of the copy. - If only a chart is selected, it is pasted into the dest as an embedded object. Primitive, but at least consistent. - Between different workbooks in the same instance of Excel. - All cells are copied as formulas. - Absolute references are copied unchanged. A ref to $A$1 in the source becomes a ref to $A$1 in the dest. - If the selection includes both cells and a chart, both are copied. - When a chart is copied, the data series refer to the source workbook. Fragile and inconsistent. Refs to the source are treated differently for cells and charts.
I can see the problem insofar graphs are involved, but I am not the least worried over the explicit case above.
"You asked for it, you got it, but this makes no sense. The formula has nothing to do with A1 and A2 in the *destination* sheet." Typically when I am copying and pasting I want exactly that behaviour. I usually paste those cells into a location such that it should refer to the same relative cells.
*** Bug 360666 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/65.