Apache OpenOffice (AOO) Bugzilla – Issue 23305
name definitions are buggy and lost
Last modified: 2013-08-07 15:15:18 UTC
The definition of names in OO 1.1 Spreadsheet is very buggy. I can reconstruct it as follow : - create a new empty spreadsheet - enter the following cell's, col A B row 1 a 10 2 b 20 3 c 30 4 d 40 5 e - create names for B1 to B5 by selecting A1 till B5 and using the menu "Insert" -> "Names" -> "Create" -> "Names in Left column" - at this point, one can check that the names are indeed created by clicking on the cells and looking at the "Sheet Area" at the left - then enter the following function in B5 : =a+b+c+d - it correctly displays 100 - however, if jou look at "Insert" -> "Names" -> "Define" one can see there are already two names lost !!! - now save the spreadsheet, leave openoffice - restart openoffice with the saved spreadsheet - now the b and d name is completly come and the formula is changed to =a+'b'+c+'d' in stead of =a+b+c+d because the b and d names are gone, one can see this also in the "Sheet Area" at te left Could someone please have a look at it, because it completly blocks my conversion to OpenOffice. I have tryed it on Linux and Windows XP : same bug exists. Because of the automatic conversion of =a+b+c+d to =a+'b'+c+'d' it has cost me some hours to find out what the trouble was, because in simple formulas like above it displays 100 correctly. Please help, because naming in spreadsheets is rather important!!! Thanks Wim Van Acker
Created attachment 11813 [details] example of the lost names b and d
Hi Sascha, is it possible that your fix for the doubled range names causes this problems ? Frank
I take it
Created attachment 12753 [details] Error sample sheet
Added sample sheet. NamesError.sxc In sheet1 all odd rangenames (nameX) are stored while all even rangenames are lost on storing te file. In sheet2 the rangenames stil are stored. However moving all ranges one row lower. All names are lost on storing In sheet3 all rangenames are lost on storing. However moving all ranges one row up. Alle names are not lost. All rangenames are created with Insert>Name>Create Conclusion: There seems to be something with even or odd numbered rows??? Hope my two cents help
PS. This is quite an issues because losing rangesnames makes that I can not trust my sheets!
*** Issue 25934 has been marked as a duplicate of this issue. ***
Hi all, as we are not able to reproduce this problem, please give us as much details about your systems. Especially OS, locales, timezone, RAM, Version of OOo (help about STRG+S+D+T) and as much info as possible on how to reproduce this failure. Thanks for your assistance. Frank
Created attachment 13693 [details] System and builds of Pieter Wolters
Hello Frank, As you asked: * Mandrake linux 9.1 but will try asap on Win98. * Sent my system in file: "Issue23305_SystemPieter.txt". * To complicate matters: OOo1.0.3 seems not to have this issue. Even stranger when OOo1.1.0 saves the file made in OOo1.0.3 ("Save As") then names will NOT be lost! Staroffice 7.0 does have this issue too! Builds I used on Linux: OOo103: SRO641, Build: 8584 OOo110: 645m19 Build 8693 SO70: 645m18 Build 8584 (evaluation version) Greetz, Pieter
Hi Pieter, can you please try OOo 1.1.1? I tried it here and it worked for me. Thanks Sascha
Hello Sascha I'm sorry, still there. 645m32, Build 8751 (OOo 1.1.1b) See file "Stillthere.jpg" Also same on Win98 (645m19, Build 8693) Pieter
Created attachment 13731 [details] shows that bug is still there in 1.1.1
PS. Sascha, Which build do you use, which system? Pieter
Created attachment 13732 [details] Bug still there 680m28 Build 8752
Hi Pieter, I tried it on Windows XP with SRX645m33 Build 8751 and also with SRC680 m28 Build 8752 and I could not reproduce it. All worked like expected. I used the eample of Wim Van Acker to reproduce the behaviour. I will also try it on a Linux and a Solaris system, but I can't imagine, that this will change something. Can you give me a step by step description what you do to reproduce it? Thanks Sascha
Hello Sascha, (Un-) fortuntly I cannot try XP. Haven't got it myself and my boss doesn't like tampering with his issued laptop ;-) I actually use the sample of Wim (perhaps he can comment himself?). Using this scheme: col A B row 1 a 1 2 b 2 3 c 3 4 d 4 When creating names Insert>Names>Create the names seem to be created. See the "sheet areabox" box but using Insert>Names>Define you see only the odd-row-numberd range names. I tried this on 680 and OOo 1.1.1 and both give the same results on Linux, (Mandrake 9.1). Step 1: Create both rows by typing a,b,c,d and 1,2,3,4 Step 2: Create names Insert>Names>Create (Tickbox "left column") Step 3: View names Insert>Names>Define (Ctrl-F3) Perhaps helping: /usr/java/j2sdk1.4.1/jre Memory per Object: 2,4MB use for OOo: 9MB Locale: Dutch Default Currency EUR (EUR symbol) Westernlanguage: Dutch Calcsettings: Date: 12/30/1899
Created attachment 13737 [details] Step by step pictures creating the problem
Hella Sascha (again), To complicate matters: I have been testing and changing OOo 1.1.0 running Mandrake. I switched to Java SDK 1.4.2_04 and reïnstalled OOo1.1.0. Situation is as follows: - When I link names "name by name" using CTRL+F3. Everything goes OK. Save file, exit, load file: names still there. - When using Insert>Names>Create. All names will be there in the "sheet area"-box (Top-left) but when using CTRL-F3 only odd-row-numbers will have names. This seems to narrow down the problem to the function of creating names and not the names them selves. Pieter
Hi Pieter, thank you for your much work. Now I could find the problem, I didn't see the forest for the trees. The fix is realy easy and also still in SRC680 m29. I will fix it now also for the OOo 1.1.2 Thanks a lot for your good discription. As I saw the pictures I found the problem. ;-) Sascha
fix reviewed and approved
fixed in sab011
please verify
reset resolution
verified on cws sab011 using Solaris, Windows and Linux Frank
Found integrated on Windows, Linux and Solaris
*** Issue 31486 has been marked as a duplicate of this issue. ***
*** Issue 39947 has been marked as a duplicate of this issue. ***