Created attachment 58812 [details] test sheet Step to reproduce use the attachment copy the sheet to another sheet and you can see that all the form field in the new sheet are still linked on the origin sheet so we can't copy any sheet that uses form control very annoying bug I think this bug is also reported here : https://issues.apache.org/ooo/show_bug.cgi?id=58415
this bug as been confirmed on the french discuss list
[Reproducible] with "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit) Due to AOOo-Bug: Inherited Not only copying complete sheets causes the unexpected behavior, even when you copy / paste a cells area with such fields in it on the same area this "strange remote checking" can be observed. a) I think the root problem is that data references look relative, but are absolute. I think absolute cell references are OK. If you accept that the references are absolute there is no bug, but I believe the current behavior is at least not intuitive. b) IMHO it's a real bug that the Form Fields loose their data reference when ou insert a new table by menu 'Insert -> Table -> From File' and select in the current file the Table you want to use as template. c) I wonder why we do not have a "Cell Selector" there (like we have for function assistant)? It should help to see relative references getting a leading "$" using that tool. This might have OASIS/ODF impact? @choffardet 'b' might be a real bug, the rest IMHO is more an enhancement request. @David: I think this relative/absolute thing should be mentioned in Help @Kohei: Any chance to get that more intuitive (Auto-addition of "$" or something else)? Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug
This problem also existed in Chart, but was (partly) solved in OOo version 3.3.0. Have a look at: https://issues.apache.org/ooo/show_bug.cgi?id=29848 copied sheet: chart-copy references original data instead of copied data This issue also contains a usefull discussion on the desired behaviour. I think this also should apply to form fields. With charts now the reverse is happening as with form fields: LO always displays absolute references to sheets. These references are hard-set to absolute by LO. IMHO this is not what most users want or expect. Since version 3.3 when the Chart is copied these seemingly absolute references are treated as relative. I think this behaviour is what most users want and expect. It is inconsistent with the displayed absolute references. For a further inconsistency, and a pitfall when changing the behaviour of form fields, have a look at: https://bugs.freedesktop.org/show_bug.cgi?id=43175 EDITING: Sheet references not correctly updated in charts when copying multiple sheets in Calc
@Rainer Bielefeld: Auto-addition of "$" is in my opinion the wrong approach. This issue is a true bug and a real time waster for users!
I agree that this is a true bug, and it is still present un LO 4.0b2
Still present in LO 4.0.0.2.
(In reply to comment #3) > This problem also existed in Chart, but was (partly) solved in OOo version > 3.3.0. > > Have a look at: > > https://issues.apache.org/ooo/show_bug.cgi?id=29848 > copied sheet: chart-copy references original data instead of copied data > > This issue also contains a usefull discussion on the desired behaviour. I > think this also should apply to form fields. this chart problem is present in Libo 4.0.x of course, workaround is easy. don't copy chart from one sheet to another expecting data references folowing the chart on the target sheet. just create a new chart. But it not the expected behavior and it's a waste of time
Hi choffardet, Let me clarify the problem described in AOO#29848, because it is somewhat different than you describe. When copying a sheet containing a chart (e.g. copy sheet1 -> sheet1_2) and the chart on the sheet1 displayes data from that sheet, then the chart on the copied sheet (sheet1_2) would still show data from the original (sheet1). Calc's behaviour starting with version 3.3 is: chart on copied sheet shows data from copied sheet (range references in the copied chart are updated: sheet1 -> sheet1_2)
The reason I mentioned aoo#29848 is that the sheet references in the data ranges are always presented as absolute (e.g. $Sheet1.A1). This implies to the user that if you move or copy a sheet the chart will still reference the same sheet. The actual behaviour of Calc >= 3.3 is that references to the chart's own sheet are in fact relative, and that it should be presented to the user as such (e.g. Sheet1.A1). IMO references to sheets should follow the same rules as references to cells: $ means absolute, no "$" means relative. Users should have the option to control this behaviour by adding or removing the $.
(In reply to comment #8) > Hi choffardet, > > Let me clarify the problem described in AOO#29848, because it is somewhat > different than you describe. > > When copying a sheet containing a chart (e.g. copy sheet1 -> sheet1_2) and > the chart on the sheet1 displayes data from that sheet, then the chart on > the copied sheet (sheet1_2) would still show data from the original (sheet1). > > Calc's behaviour starting with version 3.3 is: chart on copied sheet shows > data from copied sheet (range references in the copied chart are updated: > sheet1 -> sheet1_2) OK I understand my misunderstood. But I think that copying a chart from a sheet to anotether sheet and keeping data reference from source sheet is not the expected behavior. Maybe there should be a way to chose if the data are relative or absolute when pasting the chart ?
Still in 4.3
In reply to comment 10: The problem described here is copying _sheets_ containing check boxes / charts / whatever that contain references to the same sheet. This is different from copying an individual chart to a different sheet. IMHO the way this should be controlled by the user is by the use of $. '$Some_sheet' means always reference the same sheet 'Some_sheet' means a relative reference (just like referencing cells within a sheet).
*** Bug 97134 has been marked as a duplicate of this bug. ***