Tested against latest release version (4.0.1.2) on OSX and Windows. To reproduce: Open new spreadsheet Add new worksheet (sheet2) In Sheet2, give cell A1 a name, such as "somename". In sheet2, give cell A1 a value, such as 123. Go to sheet1. In cell A1, enter "=somename". Confirm that this works as expected and shows 123 Now delete sheet1. Observe that cell A1 in the remaining worksheet (sheet2) is still correctly named "somename" Save the spreadsheet. Re-open the spreadsheet. The cell A1 in the remaining worksheet (Sheet2) is no longer named.
Created attachment 77009 [details] Test Kit [Reproducible] with attached "newsample4012.ods" and server installation of "LibO 4.0.1.2 release - German UI / German Locale [Build ID: 84102822e3d61eb989ddd325abf1ac077904985)]" {tinderbox: @6, pull time 2013-02-28 08:53(?)} on German WIN7 Home Premium (64bit) with newly created user profile ….\LibreOffice\4012\ This bug only appears if I follow exactly reporter's instructions. I also tried a document created with LibO 3.6.6.1 and some smaller differences (3 sheets, 2 ranges), and the bug was not reproducible for me. We should do some more research what conditions are necessary to reproduce the bug.
It is significant that the sheet being deleted is in front of the sheet with the named cells. My knowledge of the internals of the spreadsheet structure is poor but I understand that internally, the worksheets are referenced primarily by index number (starting from zero) rather than name. Thus I think that the named range is referencing worksheet index number 1. This is not being updated when worksheet 0 is deleted and thus the range ends up pointing to a worksheet which has been deleted and is therefore not saved. In my application, I have a data worksheet with nearly 100 named ranges and a macro which creates many worksheets to the left of these. When the macro-created worksheets are deleted, I loose all my named ranges :-( For the convenience of my users, I want to keep the macro-generated worksheets (which they use) on the left and the source data worksheets (which they never look at) way off to the right.
I did some more tests with "newsample4012.ods": Already [Reproducible] with * server installation of "LibreOffice 3.5.7.2 Spanish UI/German Locale [Build-ID: 3215f89-f603614-ab984f2-7348103-1225a5b] on German WIN7 Home Premium (64bit) Was still ok with * Server Installation of "LibreOffice 3.4.5 German UI [Build ID: OOO340m1 (Build:502)]" parallel Server installation on German WIN7 Home Premium (64bit) So it seems this one came up with 3.5? @Andrew Beattie: Please add info concerning your OS. Can you try to find some additional conditions what switch the bug on or off?
Tested against latest release version (4.0.1.2) on: OSX 10.8.2 MS Windows 7 Professional SP1
I notice that the structure of named ranges contains both: a) The address of the range ("Sheet2.A1"), which does not change. b) A cell address structure com.sun.star.table.CellAddress. Before deleting Sheet1, this would be: .Sheet=1 .Column=0 .Row=0 After the deletion of sheet1, this should be: .Sheet=0 .Column=0 .Row=0 How can we check that this has changed correctly?
Major because bug damages documents. Already reproducible with LibO 3.5.1.2 @Spreadsheet Team Please add Witeboard tag “bibisectrequest” if you think that a bibisect result can ease your work. Please change Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug or forward the Bug if it's not your turf (and remove others in team from CC).
Still Reproducible in LibreOffice 3.6.7 and 4.1.0 RC3. This happens in ODS file, courses data loss, so I change Importance to "critical".
Targetting to correct version's MAB list then - thanks !
I guess I can take a look at this
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b5fffdb8d0438a2fe933a5742d41fe50a14b71f3 fix for fdo#62729 reference pos can point to non existing table The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Power committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7b3d8e0a7dcf6ae05e1de5c33ed382822cf52cce unit test for fdo#62729 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cb626d01772985bd0eed0f5963475d0e801379c8&h=libreoffice-4-1 fix for fdo#62729 reference pos can point to non existing table It will be available in LibreOffice 4.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
@Noel: Could you backport this to 4-0? sc/qa/unit/subsequent_export-test.cxx doesn't know loadDoc(). We could of course also only cherry-pick b5fffdb8d0438a2fe933a5742d41fe50a14b71f3 without the unit test.
(In reply to comment #13) > @Noel: > Could you backport this to 4-0? sc/qa/unit/subsequent_export-test.cxx > doesn't know loadDoc(). We could of course also only cherry-pick > b5fffdb8d0438a2fe933a5742d41fe50a14b71f3 without the unit test. yup didn't forget about this just I had no up to date local build of 40 ( should be there now ) hmm hopefully I can put some variant of the test there ( I can no longer track the differences between the unit test support between branches ) anyway I'll see what can be done quickly ( if not like you say I think cherrypicking the fix without the test will do )
Noel Power committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5073172ace5722ad1bc9ee59d39e84077bf9846&h=libreoffice-4-0 fix for fdo#62729 reference pos can point to non existing table It will be available in LibreOffice 4.0.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I confirm the bug is fixed in Version: 4.2.0.0.alpha0+ Build ID: aa5683e18de07c9e86325595ead4574efa685c3a TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_00:00:18 tested on Win7 64bit